AI(LLM)にプログラムを作ってもらう場合、ゼロから作るときはいいけどたぶん改修でつまづくと思います。それについて何が原因か、どう対策すればよいか書いていきたいと思います。
今回の記事の内容ですが、実際試してはいますが厳密な効果検証とかしてませんのでその点についてはあしからず。そういうアイディアもあるな～ぐらいに読んでください。
あと今回の話、結局の所複数人で開発することになるとぶつかる問題と同じことで対策もそれに似たものになっています。
あと台無しな事を書くと、ここに書いてある内容、数週間後には既に問題なくなってる可能性もあります(進化はやいから…)。
チャットタブを一つ開くと起きること
対策考える上でチャット窓を開いてAIと会話するときの事をまず振り返ってみます。
AIは基本的に毎回ゼロリセットされて会話が始まるので、あたらしいチャットの窓を開くと…
- 「はじめまして、今日からお世話になる開発AI 1号です」からはじまって…
(ろくに全体の説明もないまま)「君にはこれをやってほしいんだ」とピンポイントで修正内容を言われて…
「じゃあ、まず既存のソース拝見しますね～」(ものすごい勢いでソースを読む)
「(全部のソースは読んでないけど、それらしい名前のファイルを読んだので)たぶんこれだと思うので修正しますね～」
…こういう感じだと想像すると、そりゃ間違いも起きるだろうと思いませんか。
(実は正確に言うとタブどころか一回のチャット送る度に毎回新人が来てるようなもんです)
実際おきる問題
特に工夫もなくAIに改修させると何が起きるかというと…
- 既にある機能なのに別ファイルでほぼ同じ見た目、機能を作ってしまう
設計、書き方が統一されない
いくら修正指示してもバグが治らない
仮のロジック(簡易実装。常にOKしか返さないとか。)のまま動いている
…なんてことが多発します。
根本は上に書いた「タブを開くと新しい開発メンバーが来た」という状態になるからです(あと要約により情報がロストするのもある)。
新しく来たメンバーが現在どういう機能があるか知らないと同じような機能を別で新しく作ってしまいがちですし、設計や書き方説明しないと新たな設計を持ち込んだり独自の書き方をしてしまう場合があります。
こういうのが積み重なると、他はこういう書き方してるからここもそうだろうと思って修正すると違ったとか、複数同じロジックがあると片方直ったもののと片方直らないとかになるんですね。
対策案
冒頭にも書いたようにまだ十分に検証できていない案ですが対策書いてみます。
どこに何があるかまとめておく
AGENTS.mdやCLAUDE.mdにどのフォルダにどんなソースがあるか書いておくとAIも探す範囲が限定されるので見落としが減るはずです。
Serena MCPも有効です。プロジェクト内を簡単に検索出来るシステムで、AIがソースを調べる手助けになってくれます。
名前を適切につける
ファイル名や関数の名前を適切につけるのも大事です。というのもAIってわりと原始的にファイル名で検索したりしてるんですよね。人間もノーヒントだとファイル名や全文検索するので一緒ですね。
AIに随時大事な事はメモをとってもらう
最近思うのはAIがメモ残せるフォルダ作っておくと便利だなということです。最近はCodex CLIやCursorを使っているのでルートのAGENTS.mdにこれを書いています。
- 実装中見つかった問題点は `docs` 配下に、`docs/AGENT.md` 記載のルールに従い、ファイルを作成し随時記録し忘れないようにすることdocs配下のAGENTS.mdにはこんなのを書いています。
# ドキュメントの更新について
## 日付の取得
```powreshell
Get-Date
```
## ファイル・フォルダ命名規則
- `issue-(イシュー番号)-(内容[日本語許可])` のフォルダを作成し `YYYY-MM-DD_(連番)(メモ内容).md` の名前でファイルを作成する
こうしておくとイシュー毎に決まったルールでフォルダ作ってメモを残してくれます。まぁ作ってくれたり作らなかったりマチマチですけど(笑)
日付の取得を入れているのは基本AIは現在日時を正しく取得出来ないので、日付を取得するコマンドを叩いてもらう為に書いています。MacやLinuxだとコマンド違うのでAIに聞いてください。
設計はAIと一緒にやる
最近のエージェント型のAIは雑な指示でも作り始めてしまうのですが、要件と設計ぐらいは段階踏んでいった方がよいです(少なくとも2025年10月現在では)。
要件や設計ってどうすんの?というところだと思いますが、やりたいこととどう作るかを書いたMarkdownのドキュメントを作るのを目指していけばよいです。
なかなかチャットだけのやりとりではAIが考えてる事を理解するのは難しいので、一旦テキストドキュメントをAIに出力してもらって人間がチェックするような形ですね。
ドキュメントの中で疑問点があればAIに質問し、修正していきます。
不明点がないか聞く
今回の主題とはズレますが、よく私がやるのは「今の段階で決めておくことや不明点はありますか?」という質問です。これはいろんな場面で使えます。
そうするとAIは先に進める上で不明なところを聞いてきてくれます。よくわからなければさらに説明を求めるのもありです。たまに「それは良い感じにやってくれればいいよ」というあまりにも細かすぎることを聞いてくることもありますが(笑)、そこまでいけばだいたい大丈夫と判断して先に進んで良いと思います。
例えばこんな感じ。これはデータの復元機能のボタンを押したらすぐにボタンを無効化してほしいという依頼の中でのやりとりです。
Q.
修正を進めたいですが内容はわかりますか?不明点があれば聞いてください。
A.
イシュー250の内容は理解していますが、実装を進めるためにいくつか確認させてください。
理解している内容:
start restoreボタンを押して確認ダイアログで先に進めても、すぐに画面に変化がない
そのため、ユーザーが再度start restoreボタンを押してしまう
解決策として、ボタンを押してダイアログで先に進める選択をしたらすぐにボタンを無効化する
確認したい点:
対象の画面・機能: start restoreボタンはどの画面にありますか？復元機能（restore）の画面でしょうか？
現在の実装状況:
確認ダイアログは既に実装されていますか？
復元処理の実装状況はどうですか？
ボタン無効化のタイミング:
ダイアログで「OK」を押した瞬間に無効化？
それとも復元処理開始時に無効化？
復元処理の完了タイミング:
復元処理が完了したらボタンを再有効化する必要がありますか？
まず、プロジェクトの現在の状況を調査して、start restoreボタンがどこにあるかを確認させていただけますか？AIが何をどうしようとしているか、みている対象にズレがないか確認できますね。
まだソースをAIが確認する前に聞いてるので、ソースみれば分かるような事も確認してきてますね。先に調査して不明点を聞くように調査フェーズを入れるのも手だとは思います。Cursorだとこちらから言わなくても仕様検討したいというと先に調査してくれたりもします。Start Kitだと技術選定のフェーズが入ったりしますね。
これを真似するように言う
同じような処理を既に作っていればAIに参考にしてもらう為に教えるというのは有効で、これやらないとまったく同じ機能が複数の場所に散らばったりしてカオス化します。少なくともAndroidアプリをCursorで開発した時は多発しました(Codexでは起きないんだよね)。
ただ、そのためには人間が全体を把握しておかないと教えられないわけで、先の設計を一緒に作っておくというのが利いてくるわけです。
書き方のテンプレートを用意しておいてそれに合わせて書いてもらうのもよいです。テンプレート自体もAIに書かせて良いと思います。
ちなみに Speck Kitという仕様ドリブンの開発を行う仕組みでは計画中にソースのテンプレートをAIが作る工程があります。
指示に他に同様のロジックが無いか確認して作業進めるように書いておくだけでも多少効果はあるかもしれません。
公式のガイドラインでどうなってるか聞く
これも主題とはずれますが、設計や実装で専門的に過ぎて人間側で判断できないことをAIに聞かれる場合もあります。人間側でそんなことがないように知識をつけておくのが一番ですが、一般的にどうしてるか?とか公式ではどうしているか?とか使ってる技術のお作法聞くのがよいかなと思います。
AIが結果を確認できるようにしておく
これもズレるけど、効率良くAIに開発してもらう為に優先度が高い事です。
最近のコーディング用AIはエージェント的にある程度の大きさの機能を自律的に作成していくことが出来ます。その際にAIがプログラムの実行結果を確認できる環境を整えておくと、AIが自分で実行して結果をみて修正してというループを自分でやれるようになり効率的です。
たとえば単体テストをつくらせてそれを実行して確認するところまでAIができる環境作っておけば、コンパイルすら通らないコードができる確立はかなり減ります。
環境構築はいろいろとスキルが必要ではありますが、そこもAIに聞いてやってみるのもいいと思います。ただAIに環境いじらせるときは下手するとPCがおかしくなる場合もあるから気をつけてね。
レビュー
できたものを別のAIでレビューさせるのもありです。Codexの 「/review」 は結構優秀で動かしても見つかりづらいようなバグをコードから見つけてくれるのでとても助かります。
別のAIじゃなくてもレビュー専用のチャットウィンドウつくって、レビュー観点を決めておいて変更した内容をレビューさせるのもありです。
今のAIはコンテキストウィンドウのサイズに限界ありますし、辿ってきた内容に引っ張られすぎるところがあるので、新規にチャット立ち上げてレビューに専念させるとコード書いたのと同じAIなのにいろいろ見つけてくれます。
別窓のレビュー担当AIに説明するのが面倒だったら、コード書いたAIの方にレビュー依頼を書かせるのも手です。
ルールの改善
何か問題が起きたらAGENTS.mdに記載して対策していくのも大事です。
私が最初に何回かやられたのは「しれっと」テストを無効にして完成報告をしてきたことですね。
設計を大幅に変えたことでテストが大幅変更になったので一時的に無効にするというのはいいんですが、そのままにされると困ります。
AGENT.mdに追記して、作業完了時のドキュメントにテストを無効にした場合はそれを記載することをルールづけました。
改修がループしたときもドキュメントを作る
AIに改修させていると不具合から抜け出せない時があります。こういうときもどういう構造になっているか、どういう理解をしているがAIにドキュメントに出させるとよいです。そこから齟齬を埋めていくとうまく進む場合があります。
アホになってきたら別のメンバー(AI)に引き継ぎ
イメージ伝わるように「新しいタブを開くと新人開発者がやってくる」と書きましたが、実際はチャットの一回それぞれが毎回「はじめまして」なんです。
今のAIって会話がどこまで進んでるかなんて全然覚えてなくて、チャットを送ると裏で過去のやりとりが全部送られて、まったく別人のAIがそれをすごい勢いでやりとりを読み取って会話に追いついて会話の続きをしてるんですね。
なので会話が長くなるについてAIの応答が遅くなっていくし、あまり長くなると過去の会話を要約して切り捨ててしまうオートコンパクトが行われて細かい事を忘れてしまいます。
なので、アホになったら一旦仕切り直して別のチャット窓開いて進めるというのもありです。
複数人での開発のノウハウ流用ができるかも
チームで開発している人だと「人間の世界でも同じような事起きてるな…」と思われるのではないでしょうか。
なので、そこから着想していろいろ試すのはありかなと思いました。
AIにもっとおまかせ出来るようになっていくのか
今だとまだまだ上に書いたように細かいケアが必要になってくる感じで、大分ソースコード寄りの所で気を使わなきゃいけない状態ではあると思います。
ただそのうち、開発箇所毎に担当するAIをわけて、AIに読ませる資料も担当箇所に絞る。AI用の課題管理システムも用意して、自分の開発担当外に影響を与えそうなものはチケット切ったりチャットで適切な担当AIに伝えるとか、リーダー役AIに連絡上げて協議調整するとか、そういう方向にどんどんなって、もっと大きな単位の仕事をAIに丸投げすることもできるようになるんじゃないかと思います。AIが使う為のグループウェアとかそのうち出てくるんじゃないですかね。
(Devinは使ったこと無いんですが、こんな感じなんですかね。)
人間はそれでも上手くいかなかった部分について、AIが残した検討のメモや行動ログを元に原因を探り調整をしていくような形になっていくのではないかと。
ほぼ無人のオートメーション化された工場に監視役の人間が一人いて、時々止まったら様子見に行くみたいなイメージですね。
全然これは夢物語ではなくて、たぶん今でもゴリゴリに仕組み作れば似たような所までいける手が届く内容だと思ってます。金さえ払えば何十人ものSEを抱えて作るようなものも一人で作れるようになっていきそうですね。
補足
最近のAIチャットだと過去の会話覚えてるけど?というツッコミあると思いますが、あれはメモリという機能で会話を要約して時々AIが参照して答える機能がついてるからです。
実際の開発現場でもドキュメント化はされてないけど実際やってみて覚えるみたいなのはあるので、AIがそれに近い動きをしてくれると手が掛からなくなるかもですね。
(AIに対しての指摘を蓄積してどこかのタイミングでルール化するのもよいかもですね…)
