2025/10/20時点で最良のAIコーディングプロセス

2025年10月20日の僕が考えるAIコーディング（バイブコーディング）プロセスです。

個人的な結論としては、1ミリでも気に食わないコードを生成してきたら、そのタスクは最終的には破棄すべきというものです。「このコード気に食わない」「この設計気に食わない」の直感がAIコーディングで品質を維持する生命線です。

• バイブコーディング時代ではコードレビューのお局ビリティが鍵です。
• レビューに全時間を割こう。レビューに時間がかかりすぎるというより、レビューに時間をもっとかけるくらい
• 1ミリでも知らないことをなくそう

断片的なAIコーディングでいえば1年弱、本格的なコーディングエージェントを使い始めて半年以上の僕がたどり着いた結論です。

よろしければ、皆さんのTipsや感想も知りたいです。アップデートしていきたいところです。

前提

• 僕は実装だけじゃなくて、設計もさせることが多いです
• Codex使いましょう。Claude Codeとは根本的に品質が違いますよ。破滅的コードが激減します
  • マジでClaude Codeはおすすめしません
  • 僕はもうAnthropicを見限りました（もちろん、来年以後に手のひらを返してる可能性はあります！）

現状のLLMの問題

1. ちょっと問題のペーパーを見つけられないんですが「LLMは知識を持っていても、その知識を実際に活用するのは極めて苦手である」という問題を抱えています。
2. コンテキストサイズが小さすぎる。現在主流は200k〜1M程度です。

この2点を解決できない限りは、今回の記事で書いた内容が重要です。この2点が解決したら、そのときは多分AIコーディングが次のステージに行ってるでしょうね。そして、僕の読みでは、2世代は先にならないと解決しないと考えています。

もしこれがGPT-5.1とか5.5とかの次に出るGPTや、Gemini-3.0あたりで解決されていたりすれば、コーディングエージェントの性能は激変します。すくなくとも問題点を指摘すると「あ、その問題ですか？知ってますよね、こうですよね修正しますね」って言ってきてイラっとさせられるアレはなくなり、より実践的になるはずです。

Vibe Kanban や類似ソフトをおすすめしたい

Vibe Kanban前提でやるべきです。類似の何かでもいいですが、自分でコーディングエージェントを触らず「タスクを作成」「タスクを管理」「タスクを複製」できるソフトが必要です。

https://www.vibekanban.com/

1. タスクを作成したら、そのタスクの性質にもよりますが、そのタスクは作成するのみとします。これをタスクのテンプレートみたいなものにします。
2. (1)で作ったタスクを複製して開始します。途中では途中では絶対に手を出さず、タスク完了結果をレビューしてすべての判断を始めましょう。

基本的な考え方は、タスクはひたすら投げ直すです。一発で理想なタスクを投げられるとは限りません。ここで考える理想のタスクは、最初の指示のみで完全にあなたの思うタスクが一発で実行される状態です。

効率化のおすすめは、調査系タスクを大量に投げまくるです。あと同じタスクを2・3個投げるのは有効なことが多いです。

割と捨てます

実装させるのは実質無料で時間とレビューコストがかかるだけです。
なので、雑な指示で実装させて「ああ、こういう実装しちゃうんだ」を雑に観測して、その結果を捨てることも多いです。

とはいえ、指示投げ直しも限界がある

一回の指示で、すべてを伝えようとすると、どんどん大きくなる。これが、Claudeやgpt-5-codexだと簡単にキャパオーバーして変なことになるし、gpt-5でもなるべく大きくしない方がいいです。また、時間がかかりすぎます。

• 「全体像を考えず、壁打ち感覚でやる」なら投げ直しまくるのはあり。「最終的に採用しない」もあるあるです
• 修正回数がn回を超えたら根本から見直しを考える
• いやな予感がしたら、根本から見直しを考える

nは、タスクの進め方にもよりますが3〜5位を基準にした方がいいかもです。

見直す

さて、ここでいう「見直し」とはタスクそのものの前提を見直すことです。

• 分割する（特にリファクタを先に行う）
• 仕様を考え直す
• ディレクトリ構成やアーキテクチャなどを考え直す

Tips

全般で有効？

• 「TSDoc必須」
  • TypeScriptの場合、JSDocと指示せずTSDocと指示してください。
• 「adhocな改修は禁止」「adhocな改修ではなく、根本的な改修をすること」
• 「暗黙のフォールバックは絶対に許さない」
• 「合理的な理由のない、スイッチ引数禁止」
• 「合理的な理由のない、オプショナル引数・デフォルト値は禁止」
  • これは少し過激かもしれないですが、AIコーディングでオプショナル引数は不要です
• 「リファクタなので、挙動の変更は絶対に許さない。ユニットテストの変更も禁止」
  • 「ユニットテストに変更を加えたいなら、必ず合理的な理由を説明して」
• 「型安全を守ること」系
  • 正直これ指示のやり方がむずい。原則論を並べたり、eslintで防止したりとかはできるんだけど、僕も安定したやり方が見つかってないので、対話ベースで「これ気に食わない」を投げまくる感じになりがち
  • でも型で詰めまくると、全うな設計に落ち着くことが多い
• 「環境変数追加禁止」
  • やたら環境変数を追加したがることがある
• 「将来的な拡張性の考慮を禁じる」
  • open close 原則とかはあるが、そういうのではない、「過剰な夢」を語りたがる
• 「設定ファイルの書き換え禁止」
• 定期的にリファクタを投げる
  • 不要なものがないか？
  • 型安全が脅かされているところ
  • 不要な複雑さはないか？
  • テストカバレッジをあげる。バックエンドなら100%目指すべきかも
• 「調査・設計まで。許可するまで実装禁止」

今のところ全コーディングエージェント、全モデルにおいて、「暗黙のフォールバックを多用する」「やたらオプショナルを使いたがる」悪癖を観測していて、それが大抵致命的なトラブルを引き寄せます。気をつけましょう。

ただし、指示を増やしすぎると矛盾に至ることも多いです。いろいろな指示をどうやって矛盾なく与えるか？が腕の見せ所です。

追加指示

• 「この指示に矛盾や疑問点ある？ただし今回のスコープに限定して」

これを追加指示と言ってるのは、最初から指示に入れておくと、コンテキストが汚染されてよくないからです。
追加指示で投げて、その履歴をなかったことにするとコンテキスト汚染をせず、確認だけできます。

Vibe Kanbanは以前はこれができなくて「制約ある方がいいこともあるよね」って言ってたんですが、最近手のひら返しました。くるっくるです。

Codex系

• 「レポートは日本語で」
• コマンドが無限に動いててもタイムアウトしないため、注意が必要です
• 「プロジェクトについて知らない人でも理解できるコメント必須」
• 「省略しないで」
• 「このプロジェクトに入ったばっかりなので、それでもわかるように説明して」

gpt-5向け

gpt-5 ならではかもしれません（gpt-5-coddexではやらない方が言われてるもの）

• 「必要なコードを必ず全部理解すること」

bun test

bun test を使う場合は AGENT=1 bun test --bail=2 を必須にした方がいいです。bailの数値は適当に調整してください。

• bun test の出力はアホみたいに肥大化しやすく一瞬でコンテキストが超過します。AGENT=1で抑制できます
• --bail= をつけておかないとこれまた一瞬でコンテキストが超過します
• オプションや出力が独自色強すぎて、vitest に比べていろいろ失敗しやすいです。ご注意を。

eslint

eslintルールで、no-restricted-syntax とかを活用して、文法強制をした方がいいです。

過剰にプロンプトやMCPを整備しない

特定のソフトウェアにロックインされるようなやり方は避けるべきです。いまのコーディングエージェントも、LLMのモデルも進化が激しすぎるので、ほんの一瞬で陳腐化するリスクが極めて高いです。

汎用的なやり方であればいいですが、過剰適合したやり方の場合、ロックインではなくてもLLMのモデル進化によって、不要なテクニックになることも度々生じます。そしてそういうのは後ほどの「足かせ」になりがちです。

なるべく最小限を目指した方が、長期的に見て有利です。

ただし特定のMCPやプロンプトはものすごく役立ちます。ほどほどの付き合いを意識しつつもそういうったものを検証すべきではあります。

レビュー

AIコーディングでは、レビューがすべてです。100%レビューだと思ってください。

自分が1ミリでも知らないコードがあれば聞く

ほんの1ミリでも知らないコードを見つけたら、根掘り葉掘り全部聞き出しましょう。gpt-5系はとにかく省略したがるので「省略禁止。背景を全部説明して」「僕はこのプロジェクトにオンボーディング中で詳しく知りたいんだけど」などを（嘘でも）付与すべきです。

時間との兼ね合いですが、大抵の場合はやった方がいいです。

今回生まれたコード以外でも、プロジェクト内に1ミリも知らないコードがあること自体がよくないです。別タスクを立ち上げて徹底的にコードの理解に時間を割きましょう。

無邪気なおめめで質問攻めしましょう。

動作確認は必ず人間がやる

レビュー結果がOKなら今度は動作確認を人間の手でやりましょう。
もちろんE2Eテストで保証されてるなら過剰な動作確認は不要ですが、可能な限り最小限でもチェックはした方がいいです。

だいたいAIは何かをやらかします。動作確認は人間がやった方がいいです。

また、ユニットテストとかも人間が改めてやった方がいいです。「ユニットテストをすべてパスしました。カバレッジも100%を維持しています」が嘘だったケースは、今のところ僕は、全部のLLMで経験しています。gpt-5ですらこの嘘をつくことがあります。 bun test はこれがかなりヤバめです。カバレッジレポートも当てにならないことがあります。

気に食わないコードを見つけたら徹底的に詰める

基準は「気に食わないが1ミリでもあったら最後まで詰めきりましょう」です。人間相手ならレビューハラスメントになるかもしれませんがAI相手ですから。

たとえば...

• 「え？なんで動的importしてるの？importは全部宣言文でいいよね」
  • 厳密には、このレベルなら、 eslint ルールではじくのが大正解
• 「え？この仕様だったらこのコード不要になるけど、なんで無駄に複雑にしてるの？意味わかんないんだけど？全部説明して。省略禁止」
  • 最新のAIでも割とこの手のミスをしがちです
• 「え？なんでこれハードコーディングしてんの？意味わかんないんだけど」
• 「え？なんでこの指示をこういうふうに解釈したの？余計なことしないでほしいんだけど？なぜその思考に至ったか、課程を全部説明して。省略禁止」
• 「え？なんでファイル名ルール急に追加してんの？このhoge.retry.test.ts ってネーミングなんなん？ほかにこういうのないよね？なんで？なぜその思考に至ったか全部説明して。省略禁止」
• 「え？なんで設定ファイル書き換えてんの。書き換え禁止」
• 「letを多用してるのマジで気に食わない。説明して」
• 「なんでasで型アサーションしてるの？」
• 「ここ、adhocな実装してる合理的な理由を説明して。より上位レイヤーで見直して」
• 「これ何でフォールバックしてるの？意味わかんないんだけど」
• 「これなんでスイッチ引数で挙動きりかえてんの？コード複雑性増してるのすげーいやなんだけど」
• 「このデフォルト値はなんで？」
• 「この将来拡張性、なんであるの？不要だよね？なんで？ねぇなんで？」
• 「これなんでわざわざtypeof判定してんの？」
• 「このごまかしっぽいコード何？」
• 「今回 null object patternって不要だよね。ねぇなんで？」
• 「これなんでthrow/catch握りつぶしてんの？」
• 「え、なんでhogeの原則無視してんの？」

本来人間相手なら「なぜその思考に至ったの？」なんて聞くのはあまり得策ではありませんが、AI相手のレビューなら絶対にやった方がいいです。疑問点や違和感を一つでも残さないようにしましょう。実は自分たちが見つけられなかった違和感にAIが気づいてるというケースもよくあります。

さて、このように詰めまくると知性が劣化するという俗説もありますが、かまいません。徹底的に詰めましょう。

これは個人的な経験則ですが、一度でも嫌な予感がした場合に妥協して取り込んでしまった場合、長期的に見て壊れる可能性が高いからです。

つまり、AIを徹底的に詰めるのは、次のタスク指示改善のためと、今あるプロジェクトコードの違和感あぶり出しと、「今回のタスクにおける、レビュー観点」の更新のためです。

指示が増えすぎると矛盾を抱えやすくなるため、指示が増えたなーという感覚がある場合は、前述の通りに分割した方がいいです。準備タスクを入れた方がいいケースも多く、僕はそのためにリファクタを入れることが多いです。

気に食わないコードは、まず間違いなく何かしらのサインだと思った方がいいです。特に歴の長い人はその嗅覚、直感は大切にしましょう。違和感は大体放置すると危険サインです。

• 元のタスクを書き直す
• 元のタスクを一度破棄して、準備タスク（リファクタなど）をやる
• 将来のリファクタや改修候補リストに入れる

AGENTS.mdを書いたり、リポジトリの構造を気をつけても、MCP使おうが何をしても、限界はあります。僕の経験則ですみませんが、あの手この手で思いつかなかった何かしらを絶対やらかします。

感覚を研ぎ澄ましましょう。その感覚こそが鍵です。

MCPを使えばいいのでは？

品質の悪いコードを防ぐためのMCPはあります。僕はあんまり信用してなくて使ってないですが、食わず嫌いかもしれないです。有益なのがあったら教えてください。

レビューに時間がかかりすぎる問題

たぶん随所でさんざん言われつくしてる問題だと思うんですが、レビューに時間がかかります。

案: 甘んじて受け入れる

人間が書くよりは最終的には早くなるんだから、仕方ないと見なすという考え方で、僕は基本的にこれを採用しています。

案: タスクを大量に投げる

同じタスクを三つ投げて、それぞれを雑に確認、気になるコードが一番少ないやつをレビューするというのは一つの手かもしれませんが、違和感という重大なヒントを見逃す可能性は捨てきれません。

レビュー負荷との兼ね合いで決めましょう。プロダクト開発の速度感として、ちょっとした違和感程度なら無視した方がいいという判断ももちろん有効です。

案: レビュー用AIがあるじゃん？

ありです。ありですが、「どうしてそこに到達してしまったのか」は無視すべきではない情報の可能性があります。

いまのところ、人類の最後の武器は全体感による「違和感」を持てることです。冒頭で述べた問題を解決できているであろう来年の後半や再来年のモデル性能ではわかりませんが、今はまだこれが人間の重要な戦場であり、AIコーディングの品質を担保するためにとても重要です。

レビュー負荷との兼ね合いで決めましょう。プロダクト開発の速度感として、ちょっとした違和感程度なら無視した方がいいという判断ももちろん有効です。

実はもっとレビューに時間を割いてもいいのかもしれない

コーディングエージェントは、うまく使えば速度は出るのだから、そのために必要な違和感・矛盾・自分が知らないコードを全滅させれば、あとはコーディングエージェント無双できるかもしれません。

半年ほどがっつりコーディングエージェントを使ってきましたが、やり方は度々変わっています。正直どうするのが正解かなんて誰もわからないのかもしれません。あがくしかないのかもしれません。

https://www.youtube.com/shorts/VVXxYUcNkOk

結構質問にも使ってましたが、僕はここまでエクストリームにしたことはないですが、これは是非ともやるべきでしょう。

まとめ

「直感」「嗅覚」そういったものを重視する方向性で、時間を犠牲にしてでもそれらを徹底的に研ぎ澄ますのが、結局急がば回れなのでは？という結論を出しました。

ただ、レビューとかでやたら詰めるの、癖になっちゃうと人間相手で困ることをしちゃいそうなので、そういうところはちゃんと切り替えていきましょう。