AIがコードを書いてくれる時代、我々は何を確かめるのか

Qiita Conference 2026 Autumn

Transcript

1. AIがコードを書いてくれる時代、 我々は何を確かめるのか Qiita Conference 2026 Autumn Yosuke Furukawa 2026/10/28
2. X: @yosuke_furukawa GitHub: yosuke-furukawa
3. 宣伝 • JSConf.jp 11/22 (日) 開催！！！ • JavaScript を作ったオリジナルオーサーである Brendan Eich 氏登壇（録画） • その他豪華ゲスト登壇予定
6. 滑り終了
7. AIがコード書いてくれるようになっ てしばらく経った
8. こんなことを聞かれるようになった
9. こんなことを聞かれるようになった • レビューってしてますか？ • レビューの時どんな観点でしてますか？ • AIがコード書いて、AIがレビューしてて、俺等いるのかなって思いませんか？ • (ひょっとして病んでる？) 総じて言うと、レビュー・確認っていりますか？ って聞かれた
10. シンプルに答えるなら • もちろんしたほうが良い。 • コードのオーナーシップ（自分のものであるという自覚）を持つため。 • 「AIがアウトプットしたコードなので、自分は知りません」という言い訳は 誰にも通用しない。
11. 一方で・・・ • しかし、「オーナーシップを持つのはレビュー以外の手段もある」というの も理解する。 • 「AIが生成したコードでレビューもAIがしているが、責任は自分に帰属して いる。隅から隅までを把握しているわけではないが、問題があったら自分の 責務は全うする。」というのは成立するように思う。
12. まさに過渡期 • なんとなく、縁がある開発会社や知り合いを元にこの質問 • レビューしてますか？どんな観点で？というのは聞いてみた。 • ほとんどの会社では「人間がレビューしている」 観点は「コード品質や可読性観点」「メンバー育成観点」「仕様上合致して るか観点」「QA観点」などなど • 一方で「人間のレビューを完全にやめて高速に出すこと」に振り切っている という会社もあった
13. そもそもコードレビューってなんでやってたんだっけ？ • 問題をリリース前に見つけて修正するため • コードベース、コンテキストを理解する事でチーム間の共通認識を作る • この共通認識がオーナーシップにつながる • チーム間の共通認識を作る過程で育成にもつながる AIがコードを書く上で 他社がどうしてるのかは参考にしたい
14. AI 企業たちはどうしてるのか？ • Anthropic 社 • 全行コードレビューはしていない • お金を扱うところやセンシティブなところはリスクを考えて人がレビューもす る • 基本的には `/code-review` , `/security-review` を都度かけて判断、最後の最 後に他者がレビューするのはセンシティブな部分だけで、事前にオーナーが自 動チェックで直せるところから直す • https://claude.dev/blog/solving-code-review-at-anthropic/
15. AI 企業たちはどうしてるのか？ • Anthropic 社 • でも、インシデント発生時は担当者が評価される。責任を伴った動きができたか を元に評価。 • アーキテクチャに関わる大きな判断はアーキテクチャレビューを受ける • AI以外の人の承認がマストなものはそれがないとマージされないフローになる • 結果責任を伴わせた育成と人のレビューによるハイブリッド運用 • 目標は、人のレビュー時間を減らしても、差し戻しや障害を増やさないこと。単 に承認を省くのではなく、それを可能にする検証と復旧の仕組みを整えている。
16. AI 企業たちはどうしてるのか？ • OpenAI 社 • Symphonyというプロジェクトで実験的にほとんどレビューしないで出すように した。 • Linear プロジェクト管理ツールでエージェントに指示 • 曖昧さが強いか複雑性が高いものに関しては人間が細かくチェック • それ以外は自動でレビューしてマージ • https://openai.com/ja-JP/index/open-source-codex-orchestration-symphony/
17. AI 企業たちはどうしてるのか？ • OpenAI 社 • ここでもやはり、タスクを分類したうえでレビューは実施している（高複雑であ いまいなもの） • 人が成果物を直すだけでなく、次回成功できるようにテスト・文書・ツール・制 約を改善する（ハーネスの更新）。 • 細かく作業を監督する負担を減らし、計画と成果の判断に集中するようにした • ここでも同じく、レビュー自体は実施し、チームビルディングにも貢献している • あくまでワークフローを変えているだけで、責任範囲は変わっていない
18. コードレビュー • それ自体は価値を失っていない • いかに効率を上げてエンジニアが集中して見てもらう環境を作るかに各社注力 されてる • 全行コードレビューのような事をすると集中力が削がれる • 集中力はエンジニアの共有リソースであるという認識がある • またインシデントが発生した場合に責任範囲が移ることもない • なので、如何に集中するか、如何に責任を持たせるかでオーナーシップを持つ 意義は変わらないという事になる
19. というわけで、AI時代でも重要なコードお よび成果物はレビューしないといけない
20. じゃあレビューを どこまでするべきか
21. 品質基準に照らして 何をどこまでやるか
22. 品質基準 • コードレビューも一部肩代わりできるように、品質基準も一定まではAIで作 り込んで守らせることは可能 • 一定言語化したらハーネスやループに組み込めるはず • 一方で、品質基準は変わりうる • ゴールが一定じゃなく、変動するため、都度更新が必要になる
23. 品質基準が変わる例
24. 何と言っても最近騒がれてる脆弱性対応 • PHP2Shell にせよ HTTP2Shell にせよ • リモートコード実行が可能という事で騒がれているが、メモリ領域範囲外に 書き込めてしまう脆弱性を使い、それを任意コードのアドレスとして利用し ようとする攻撃 • 正直これまでだったら「どっかでアプデしておきますね」で終わってたはず • 今や一旦停止までして徹夜で対応に追われる • 品質基準がいきなり変わってしまった
25. 脱線 • PHP2ShellやHTTP2Shellみたいなのは今後も増えると思う。 • こういった脆弱性や攻撃について「正しく怖がれる」ようになってほしい • 怖がらなくて良いということではない • 基本的に何回も試行しないと成功しない脆弱性であり、いきなり一撃で起こせるほ ど簡単な攻撃にはならない、 • 一方で AI で攻撃しまくってどっか当たればラッキーみたいな攻撃は存在するし、何 万回と試行してペネトレーション成功した攻撃もある • 今まで大丈夫だったけど、これからも大丈夫とはならない、正しく怖がろう
26. 脱線終了
27. 品質基準は変わる • 品質基準は基本的に変わっていく • 基準の変化にいち早く応じてコンテキストや入力を変えるのも人間のエンジ ニアにしかできないこと • 基準に合わせて「どこを色濃くレビューするか」を変えていく必要がある • 今回のセキュリティの例で言えば情報漏洩リスクに対してこれまでのコード も含めてレビューをする必要が出てきた
28. 品質基準は変わる • ちなみにセキュリティだけじゃない • プライバシー保護、アクセシビリティ、パフォーマンスなどの要件は基本的に 外部から来る • 品質基準の変化に追従できるようにするためのセンサーは持ち続ける必要が ある • それには技術的な知見もさることながら、製品以外の情報にも興味や関心を 持ち続ける必要がある
29. 品質基準は変わる • 品質基準は基本的に変わっていく • 基準の変化にいち早く応じてコンテキストや入力を変えるのも人間のエンジ ニアにしかできないこと • 基準に合わせて「どこを色濃くレビューするか」を変えていく必要がある • 今回のセキュリティの例で言えば情報漏洩リスクに対してこれまでのコード も含めてレビューをする必要が出てきた
30. まとめ
31. まとめ • コードレビュー、AI時代もやったほうが良いの？ • やるかやらないかの二元論じゃない • 濃淡を付けてやらないところは自動化・効率化 • 複雑性・重要性・曖昧さに応じてやるところは集中して深く見る • ハーネスに組み込んで自動化とかもやっていった方が良い • じゃあどこまでやるの？ • 品質基準が満たせてるかどうかになる • 一方で品質基準は移動する • 特にセキュリティの温度感は昨今上がってる
32. まとめ • 決めた基準を満たしているかは、AI に確認を任せられる。 • 何を基準にし、どこまで求めるかは、プロダクト側の判断として与える。 • その基準が今も十分かは、実際の利用や変化を踏まえて見直す。 • 基準が変わっていくことに対して正しくセンサーを働かせる必要がある • センサーを働かせるには好奇心の広さ・深さ、技術力が必要 • 大変そうに見えるけど「一人じゃない」から、みんなで守ろう