こんにちは！採用担当です。パーソナルコンピュータの父と評されるアラン・ケイ氏をはじめ豪華スピーカーを招聘して開催されたニジボックス主催のイベント『POST Dev 2025』。今回はその初日に行われたトークセッション「AI✕NIJIBOX：AIどう使ってる？その効果は？どう浸透させようとしてる？」の模様をお届けします。

本セッションではニジボックスのフロントエンドエンジニアが登壇し、開発現場でのリアルなAI活用事例や具体的な効果、社内での浸透の取り組みなどについて語りました。現場の“リアル”に迫るエンジニアたちの本音トークをご覧ください。

「AI✕NIJIBOX：AIどう使ってる？その効果は？どう浸透させようとしてる？」

主なトークテーマは…

＃どんなツール使ってる？

• • 開発現場で使われるAIツールの変遷
  • シームレスに使える『Gemini』の優位性
  • AIは「副操縦士」から「ドライバー」へ

＃どんな使い方してる？

• • 「雛形」を作ってから任せる開発スタイル
  • 既存コードとルールをAIに読み込ませるエンハンス業務
  • お手本のない「新規開発」こそ、設計の言語化が重要　

＃どんな効果が得られた？

• • 見積もり精度は道半ば。しかし…
  • FE完結案件では「プルリクコメント」が半減
  • AIで「チェックツール」を作成し、目視確認を自動化

＃AIフル活用の開発合宿

• • AIでアウトプットが激変！？

【登壇者】

古川 陽介｜ニジボックス デベロップメント室 プロダクト推進1部
鈴木 那奈｜ニジボックス デベロップメント室 プロダクト推進1部
五井 瑠衣子｜ニジボックス クライアントソリューション部 フロントエンド3グループ

＃どんなツール、使ってる？開発現場で使われるAIツールの変遷

古川：このセッションは「AI×ニジボックス」として、現場でどうAIを活用しているかをお話しします。私、古川陽介と、鈴木那奈さん、五井瑠衣子さんの3名でお送りします。まずは「ツールは何を使っていますか？」というところからはじめましょう。

僕は基本的に『Claude Code』を使っていますが、ここに至るまで結構変遷があります。2024年は『Microsoft Copilot』から始まり、『Cline』、『Cursor』を経由して『Claude Code』、いまは『Codex』も併せて使っています。片っ端からやってみた感じですが、時々で強み弱みはあります。ただ、深く知る手前で新しいツールが出てしまうんですよね。

例えば『Cline』は評価する水準まで使いこなせていないんです。その前に『Cursor』がはやってしまって。『Cursor』は既存コードを読み込ませて補完してくれるのがすごく強かった。『Cline』はエージェントベースの動きをするので、エージェントの頭の良さが出力結果にひも付いてしまう。僕がプロンプトに慣れていないのもあったと思いますが、きちんと評価しきれなかったのが正直なところです。そして、いまはもっぱら『Claude Code』なのですが、鈴木さんは何を使っていますか？

シームレスに使えるのが『Gemini』の優位性

鈴木：開発の拠点では『Cursor』を使っています。コードが絡まないところでは、ニジボックス全体で『Gemini』なども使っているので、資料作成時に相談するのは『Gemini』ですね。

古川：社内用の生成AIソリューションTとして『graffer』もありますよね。

鈴木：『graffer』は『Gemini』の前にずっと使っていましたが、いまは『Gemini』がメインです。使い勝手の問題で、『graffer』は毎回ログイン認証が必要でした。『Gemini』はシームレスに使える点が圧倒的に優位ですね。

古川：開発は『Cursor』なんですね。五井さんはどんなツールを？

五井：2年半ほど前に『GitHub  Copilot』が早い段階で導入され、6月からは『Amazon Bedrock』経由で『Claude Code』を従量課金で使っていました。ただコストを気にする必要があったので 『GitHub  Copilot』と併用していました。

ただし7月から『Claude Code』に MAX 200プランが適用されたため、そこからは『Claude Code』中心に使うようになりましたね。

古川：要件定義も『Claude Code』を使っているということですか？

五井：要件定義では『Gemini』と『Claude Code』のプランモードを使い、両方でいいとこ取りみたいな感じで使ったりしていました。

AIは「副操縦士」から「ドライバー」へ

古川：それぞれ使っていく中で『Microsoft Copilot』から『Claude Code』に移ったわけですが、体感はどうですか？

五井：まるで物が違います。『Microsoft Copilot』の時はタブでコード補完をしてくれ、あくまで補助的という位置付けでした。しかもタブで出てくる候補も思ったのと違うものが結構出てきて「それじゃない」と。割と邪魔になる時もあり、結局自分で組んでしまうことが多かったです。

でも『Claude Code』は「全部やってくれる」みたいな印象が最初にあって。体感としてはまるで違う、すごいものが出てきたなというのが正直なところですね。

ただ、しばらく使っているとコード品質やコンテキストウィンドウの肥大による精度の低下など課題も見えてきます。単純にツールを導入するだけでは駄目なんだと実感しています。

古川：確かに僕も同じような変遷をたどっています。最初は補助ツール、つまりAIが「副操縦士」でした。自分が操縦士でAIが副操縦士という立ち位置。だけど2025年からは完全に逆転し、AI側が「ドライバー」としてハンドルを握っている感じがあります。

ではこれらのツールを実際に案件に適用するとどうなのか、というのが次のトピックですね。

＃どんな使い方してる？「雛形」を作ってから任せる開発スタイル

古川：僕は開発は『Claude Code』に要件を投げて実装してもらうケースが多いです。最初は言われたものをそのまま書き起こし、仕様っぽく膨らませたものを上から順に実装させる、みたいな感じでやっていたんです。

ただ、そのやり方だと途中から完全にブラックボックス化してくるんですよね。途中までは仕様も中の実装も把握できているんですけど、本当に他人が書いたコードみたいになってきてしまう。

そうした失敗を何度か繰り返すうちにある程度の雛形はこちらで作ってから、その雛形に合わせて実装させるほうが効率的だなと思うようになりました。最初は要件をまるごと投げていたんですが、ある程度コアなところは自分で実装し、差分をAIに任せるやり方が良かったです。

たぶん最初のお手本が必要なんだと思うんですよ。お手本があると、それに応じて「ソースコードの置き場はここなんだな」とかやってくれますよね。

既存コードとルールをAIに読み込ませるエンハンス業務

鈴木：私たちのチームはサービスのエンハンス業務が中心です。新しいものをガンガン作っていくよりは既存のコードを基に機能を追加したり、ブラッシュアップしたりするところがメインの業務です。

先ほど古川さんがおっしゃっていたみたいに、最初の雛形みたいなものは「既存コードを参考にしてくれ」とAIに指示したり、あとは「こういう構造だから、こういうコーディングルールでやってくれ」とAIに指示してコードを生成してもらっている感じです。

古川：そのコーディングルールは、『Cursor』のRulesでMDCファイル化しているんですか？

鈴木：はい。『Cursor』のRulesで今まで使っていたコーディングルールも全てMDC化し、HTMLならHTML専用、CSSならその専用のルールという感じで作っています。

古川：このルールを明文化するのも大変だったんじゃないですか？

鈴木：私たちのチームは結構ドキュメントをしっかり作っていたのもあり、それをコードに落とし込んで伝えるのであれば難しかったと思いますが、日本語でマークダウンにするだけで良かったので、そこのつなぎ込みは比較的楽にできたのかなと思っています。

古川：あと見積もりのところもやっていますよね。

鈴木：そうですね。チームの課題として、開発の工数見積もりと実案件の工数の間に乖離が発生している問題がありました。自分たちで要件を把握し詳細見積もりまで出して進めていますが、実際コードを見ると意外と時間がかかりそうだとか、見えていない要件に気づけず実工数がすごくかかってしまったといったことが発生していました。

それを解決したくて『Cursor』と見積もり段階から要件を相談しながら、整理して作っていくみたいなことをMDCファイルの方でやっています。

古川：こちらが見落とさないように、見積もり用のルールを作って壁打ちしていくと「こういうのって忘れてない？」と事例から引っ張ってきて答えてくれる、ということですか？

鈴木：そうですね。「ここ気を付けるべきところあるかな」みたいなところが、対話によって整理されていく感じです。

古川：面白い使い方ですね。後でどれぐらいの効果があったのか聞かせてください。では次に、五井さんの話を聞きましょう。いまどんなふうに使っていますか？

お手本のない「新規開発」こそ、設計の言語化が重要

五井：私が携わってるプロダクトは2つあり、1つは鈴木さんと同じくエンハンスになっているものです。オンボーディング資料やテスト戦略もかなり言語化を頑張っていたのでエンハンスで使う分には、すごくうまく動く印象がありました。もう1つのプロダクトは新規開発です。

古川：既存エンハンス開発と、新規開発もやっているんですね。

五井：はい。しかも既存の方は1～2年ぐらい前にリアーキテクチャして構造も整えたんです。LMMはまねするのが得意なので、お手本になるコードがあるとそれをまねして作ってくれる特徴があるかなと思っています。ただ、新規開発はお手本がないんですよね。

どこをまねしたらいいか分からない状態なので、新規開発で大事なのは最初の設計。要件定義と詳細設計、実装計画のところをしっかり詰めていかないと、うまく『Claude Code』も動いてくれないと最近すごく実感しています。ふわっとした指示を出しても全然良いコードが返ってこないので、そこの言語化をしっかりやらないといけないなと感じています。

古川：そうですね。それとなく動いちゃうところが、またまずいところですよね。一見それっぽいの出てきたりしますもんね。

五井：やはり専門的な知識が必要だなと思っていて。そこのジャッジができないと、最終的に技術的負債の塊ができちゃって更新したり新規追加する時に辛くなってしまいますよね。

古川：非常に分かります。僕もあるプロジェクトで専門ではないネイティブアプリを作ることになった時、生成AIに全振りでやってみたらそれっぽいのはできるんですよ。でもいざ本番プロダクションで実行すると、なんかの操作をしたタイミングでクラッシュする。しかもクラッシュログを見ても何が起きているのか全く分からない。

五井：自分自身の弱いところは弱いままなんですよね。強い部分はブーストしていけるんですけど、やはり生成AIが出したコードをそのまま受け入れるわけにもいかないので、ちゃんとレビューするとなると…苦手な分野のコードレビューはめちゃくちゃ調べて正しいか判断しないといけないので、結果すごい時間がかかるっていう。

古川：いかにAIが進化したとしても、僕らにとって知識や経験が不要になることはないんですね。ただアプリケーションを書く、ライティングするところだけは確かに効率化されてはいるんで、そこは使っていかないと損だよねっていうのはその通りだと思います。

＃どんな効果が得られた？見積もり精度は道半ば。しかし…

古川：ここからは実際に使ってみての効果の話です。まず、鈴木さんが使っていた見積もりの話。実際どういう効果があったんですか？

鈴木：まず見積もりなんですが、すごく正確な見積もりができてるかと言われると正直ちょっと…見積もり自体の精度はあまり高くないのかな、というのが現状です。

ですが、先ほども触れた『Cursor』と相談して要件を整理できるところはすごく活用できています。その壁打ちによって「このパターンもありますよね」と『Cursor』が出してくれて、おかげでパターンを不足なく開発に納品できたところもありました。結果的に見積もりという点じゃないところで、納品後に「直してほしい」と言われる数が減るという効果が得られています。

古川：手戻りが防げた、ということですね。

鈴木：はい、品質は上がっているんじゃないかなと実感しています。

FE完結案件では「プルリクコメント」が半減

古川：ほかにも、開発のプルリクエストの指摘の数でも測ってましたよね。

鈴木：そうですね。プルリクエストのコメント数も指標として測っていました。見積もりのRules以外にもセルフレビューのRulesも作っています。今までもチェックリストとして別で管理していましたが、それをいちいちチェックするのが面倒だったり、抜け漏れがあったりしてなかなか機能してなかったんです。

それを『Cursor』のRulesで自動化させることで、そこのチェックをしっかりしてからプルリクエストを出すフローに変えたんですね。

古川：出す前に『Cursor』に「見積もり」と言うと自動で動き、差分で正しくコードができているか見てくれると。

鈴木：はい。それがあることでプルリクエストのコメント数が減るんじゃないか、みたいな仮説を立ててやってみました。

案件の種類として開発納品が必要な案件とフロント側で完結する案件があり、開発納品が必要な方は残念ながらコメント数が増えてしまいました。ただ、フロントエンドで完結する案件では1/2ぐらいにコメント数が減ったという測定結果がでています。

AIで「チェックツール」を作成し、目視確認を自動化

古川：五井さんはAIでの取り組みに対して効果を測ったりとかしてますか？

五井：測ってはいないのですが、最も効果が高かったのはチェックツールですね。QAの部分なんですが、これまでデータの整合性は目視チェックが多かったんです。そこを「チェックツール作って」と『Claude Code』にお願いしたら、割とサクッと作れて。人間が目視で確認するより機械的にチェックを入れた方が正確に判断できるので、すごく効果が高かったなという実感はありますね。

古川：なるほど。入稿データツールと、それをチェックするチェックツールの2種類を作った、ということですかね。

五井：そうですね。今まで手打ちでやっていたところを自動化したい、確認作業も自動化したいというところです。

古川：いずれにせよ、自分たちの開発の手元で使うためのツールとして開発をしてみたと。

五井：結構、TypeScriptの型がすごい仕様書代わりになるなっていう実感があって。

古川：TypeScriptの型の情報がですか？

五井：そうです。フロントで保持しているデータが結構複雑な構造なんですが、TypeScriptの型の情報もきちんと読み取ってくれて、CSVのデータもきちんとマッピングしてくれるので。やはり「型」って強いなって思いました。

古川：型のパラメーターからちゃんと推測してくれたりしますよね。逆に既存の型のパラメーターの名前があやふやだと、すごい混乱してるのが見えますよね。

五井：なので構造化データを渡すのってすごい大事だなと。

古川：鈴木さんは既存の開発ワークフローを効率化するために、AIに肩代わりしてもらうとか、チェックしてもらう。一方で、五井さんはそのチェックするためのツールを作るのに使うっていう、ちょっとメタな使い方をしてるんですよね。

AIにサポートするツールを作ってもらい、そのサポートするツールと共にやったらうまくいった、みたいな話は結構出てきてるんですよ。だから、五井さんの使い方は後者に近くて。選択肢としてどっちもあると持っておくといいかもしれないですね。

＃AIでアウトプットが激変！？AIになじむ、親しむ開発合宿

古川：先日、AI開発合宿をやりましたよね。お二人とも参加されたと思いますが、今回の開発合宿は『Claude Code』を使ってアプリケーション開発をやってもらいました。それぞれ、これまでの開発合宿よりアウトプットの品質や内容がかなり変わったなと少し思っていて。そこについての印象をお二人に聞いてみたいなと思いました。

鈴木：印象に残っているのは、『ハムちゃんジェネレーター』みたいなのがありましたよね。某アニメのハムスターキャラのハム語、ハムちゃん同士の挨拶を使って発表してくれたんです。その人にあったハムちゃんを作ってくれるみたいなやつがすごい印象に残ってて。もうめっちゃ笑っちゃったんですけど、面白いのができたなあと思いました。

古川：鈴木さんが作ったのは何でしたっけ？

鈴木：雰囲気タグを選んでテレポートを押すとGoogle APIにつないで、きれいな場所などを表示できるどこでもドアジェネレーターみたいなのを作りました。

古川：じゃあ、五井さん、なんか思い出に残ったやつは。

五井：私が印象に残ってるのはニジソニックという架空の音楽フェスで。架空のアーティストのネーミングがとにかく面白くて。AIが考えたのかなってのがちょっと気になりました。

古川：某音楽フェスをパロディしたランディングページですよね。開発合宿の最後ってお祭り感があるから、笑わせたもん勝ちみたいなところありますよね。ちなみに五井さんチームが作ったアプリは何でしたっけ？

五井：お天気とパーソナルデータに基づいた服装提案アプリを作りました。パーソナルデータとは自分にあったカラーや、その日のモード、例えばお仕事だったりデートだったりといったデータをその日のお天気とともに入力するとベストなファッションを提案してくれるという。

古川：自分のためのアプリというのはクオリティが担保されてなくてもいいので、そこがすごく面白いなと思います。みんなが思い思いのものを、自分のいま困ってることになぞらえて作るのは良かったなと思いました。

開発合宿ってAIを浸透させる上で最も適していると思うんですよ。社内でもまだAI何するものぞ、みたいなところがありますよね。そういう時は「まず触ってみようよ」というのが一番なんです。

触ってみて知見を確認しながら、そこからどうやって開発にひも付けていくか考えていけばいいんじゃないか、というのが僕の持論です。実際やってみると見事にみんなが本当にいろんなアプリを作ってきたし、1日中みんな笑って開発してる様子を見て良かったなと思いました。

ということでニジボックスではこれからもAIをあらゆる角度から試し、使って、活用していきます。その中からベストプラクティスみたいな道筋がきっと見えてくると思います。本日はお二人ともありがとうございました。セッション参加者のみなさまもありがとうございました！

鈴木・五井：ありがとうございました！

今回のセッションではニジボックスの開発現場におけるAIのリアルな活用法と、そこから見えてきた課題、得られた具体的な効果についてざっくばらんに語られました。開発合宿のように楽しみながら新しい技術に触れる文化と、鈴木さんや五井さんのように実務課題の解決にAIを役立てようとする現場の試行錯誤がマージし、ニジボックス全体でAI浸透を加速している姿が垣間見られました。

ご興味を持たれた方はぜひご応募ください！