AIが書いたコードをレビューするな
https://zenn.dev/a_1ro/articles/74f187caab79d0
はじめに
AIが書いたコードを一生懸命レビューしているあなた。残念だが、その作業は今日で終わりにしていい。
2026年3月、InfoQがある調査結果を報じた。「AIコーディングアシスタントは開発速度を上げなかった」。理由は単純で、コーディングは元々ボトルネックではなかったからだ。
では本当のボトルネックは何か。それは「認識のズレ」だ。
レビューすべきはコードじゃなくて前提だ。「テストは書くよね？」「外部依存は増やさない方向だよね？」——その暗黙の期待を、実装が始まる前に言語化して合意する。それだけでコードレビューが「驚きの連続」から「確認作業」に変わる。
この記事では、そのフローを Claude Code のスキルとして実装して実際に使ってみた体験を書く。
課題：「作ってもらったけど違った」の繰り返し
AIと仕事していると、こういうことがよく起きる。
- 「○○を実装して」と頼む
- AIが実装してくれる
- コードを読むと「あ、テストコードないんだ」「ここの型、any になってる」「外部依存が増えてる」
- 「そうじゃなくて…」と修正依頼
- また読む
この「作る → 読む → 直す → 読む」のループが地味に消耗する。根本的な問題は、自分の頭の中にある前提（「テストも書いてくれると思ってた」「外部依存は増やさない方向で」）が、依頼文に書かれていないことだ。
プロンプトを磨くのは矢印の向きが逆
「プロンプトを詳しく書けばいいのでは」と思う人がいるかもしれない。でも矢印の向きが違う。
プロンプトエンジニアリング: 人間 → AI（自分が書いて渡す）
intent-align: AI → 人間（AIが仮定を出して、自分が確認する）プロンプトをどれだけ丁寧に書いても、「書いていない前提」は伝わらない。書いていない前提は、自分でも気づいていないことが多いからだ。
AIに先に仮定を言語化させることで、自分が気づいていなかった前提のズレが初めて見える。
解決策：実装前に「仮定リスト」を出してもらう
自分が試したのは以下のフロー。
1. タスクを伝える
2. AIが「私はこれをこう仮定して動きます」というリストを提示
3. 自分が各前提に Yes / No / 条件付き で返す
4. No が出たら対話して修正・再提示
5. No がゼロになったら実装スタート
6. 合意した前提リストがファイルに記録されるポイントは 「AIが勝手に判断していた部分を全部見える化する」 こと。
実際に使ってみた：npm パッケージ実装
今日、rageval-sdk という npm パッケージの実装でこのフローを初めて本番投入した。
規模感としては小さめ（公開関数2つ、外部依存ゼロ）のパッケージで、「前提確認フローの動作確認」にちょうど良いサイズだった。依頼内容は「track() と atrack() の2関数を持つ TypeScript npm パッケージを作って」という単純なもの。
AIが出してきた前提リストの一部がこれ。
前提確認リスト
1. 関数スコープ: track() / atrack() の2関数のみ ← Yes
2. パッケージ名: rageval-sdk（npm で未使用を事前確認） ← Yes
3. ビルド: TypeScriptファースト、CJS+ESMデュアルビルド ← Yes
4. 外部依存: なし（Node.js 18+ 標準 fetch を使用） ← Yes
5. ランタイム: Node.js 18+ ← Yes
...
9. テストコード: 軽いスモークテストを含める ← **No（Vitest でしっかり書いてほしい）**前提9が「軽いスモークテスト」になっていた。自分は「しっかりしたテスト」を期待していたが、依頼文に書いていなかった。
ここで「No、Vitest でカバレッジも含めてしっかり書いてほしい」と返す。AIが修正して再提示。No がゼロになったところで実装スタート。
結果：Vitest テスト 16件、外部依存ゼロ、PR まで一発。 コードを読む時間がほぼ不要だった。「合意した通り動いてる」という確認作業で終わった。
何が変わるか
従来
intent-align
AI実装 → コードを読んで理解 → 「これで合ってる？」を判断
前提リストを確認 → 合意 → AI実装 → 「合意通り動いてる？」を確認
理解と承認が同時に起きる（認知負荷が高い）
理解（前提対話）と承認（実装確認）が分離される
コードレビュー = 予期しない発見（驚き）の場
コードレビュー = 期待通りか確認する場
コードレビューが「驚きの連続」から「確認作業」になる感覚、というのが正直な体感だ。
Claude Code スキルとしての実装
このフローを Claude Code のカスタムスキル（/intent-align）として実装している。
スキルは .claude/skills/intent-align/SKILL.md に置くだけで使える。核心はこの2つだ。
前提カテゴリ（Step 1）:
カテゴリ
例
既存コードの挙動
「このAPIは常に200を返す前提」
スコープ
「エラーハンドリングはログのみで十分」
優先順位
「パフォーマンスより可読性を優先」
副作用
「DBへの書き込みが発生する」
非対応事項
「モバイル対応は今回やらない」
フィードバックループ（Step 2）:
- Yes — そのまま進める
- No — 前提を修正して再提示
- 条件付き — 条件を追記して再提示
No または条件付きが残っている間はループを続ける。すべて Yes になったら実装へ。
/intent-align ○○を実装して と呼ぶだけで動く。合意した前提は tasks/ 配下にファイルとして残るので、「なぜこの設計にしたか」の記録にもなる。
まとめ
AIがコードを書く速度は今後も上がり続ける。だがAIは「何を作るべきか」を決められない。仕様を言語化し、前提を可視化し、合意を形成する——これが2026年以降のエンジニアのコア職能になる。intent-align はその最小単位の実践だ。
「AIがコードを書いてくれる速度」より「自分がそのコードを受け取れる速度」の方が今は律速になっている。intent-align はその律速を前倒しして解消するアプローチだと思っている。
次の記事では、このスキルを含む「Claude Code + Obsidian Vault による個人 OS アーキテクチャ全体」について書く。前提確認フローは、その大きな仕組みの一部に過ぎないので。