AIがコードを書くことによる不安

開幕の対談：コードがブラックボックスになるとき

拾聞：昨日、Hacker Newsに人気の投稿がありました。Metaのエンジニアが、長年コードを書いてきたが、初めて仕事がこんなにも不安定だと感じたと述べていました。彼の言葉の要約は以下の通りです：今、コードを書くとき、自分がブラックボックスと共に仕事しているように感じます。上位レベルのロジックは理解できますが、各詳細については必ずしも理解しているわけではありません。これは新しい業界の常態になりつつあるかもしれません。どう思いますか？

永亮：その投稿を読んで、核心的な不安はAIにあるのではなく、「理解」という行為の境界が変わったことにあると思います。17年間技術に携わってきて、最も多くの時には70人チームを管理してきました。以前は、エンジニアが提出するコードは、一行ずつ明確に説明できるものでなければならないと皆が考えていました。しかし今、その基準は緩んでいます。基準がなくなるほどではなく、「各詳細をどの程度理解すれば責任があるか」という基準に変わってきています。これが今回の番組で最も明確に話したい点です。

拾聞：つまり、AIによるプログラミング支援を批判するため来たわけではないのですね？

永亮：そうではありません。私のチームでは既にAIを使ってテストを行ったり、注釈を追加したり、古いコードを修正しています。確かに速いです。しかし、速いだけで問題が起きたら誰が責任を持つのでしょうか？これは管理者が避けられない問題です。今日は、現象、個人的経験、チームのメカニズム、反対側の境界という4つの観点から、この不安を分析してみたいと思います。

Q1：そのエンジニアの不安は何なのか

拾聞：まず現象を明らかにしましょう。そのMetaエンジニアの不安を一言で表すと何ですか？

永亮：彼が恐れているのは、AIが悪いコードを書くことではなく、自分が完全に理解していない製品を提供していることです。この言葉を事実ベースで言うと、「You understand the high level, but not every detail.」となります。

拾聞：このような不安は代表的なものですか？

永亮：非常に代表的です。しかし、これは古い不安が新しい形を取っただけです。以前も不安でした：ライブラリは自分が作ったわけではない、フレームワークも自分が作ったわけではない、クラウドサービスの基盤も自分が作ったわけではない、なぜそれらを使う勇気があるのか？答えは、「信頼の階層」を築いたからです。Linuxカーネル、React、AWSを信じるのは、それらが大量のテストと実際の運用を経ているからです。AIがコードを生成する問題は、必ずしも間違っているということではなく、「信頼の階層」がまだ十分に築かれていないため、すでにメインブランチに組み込んでしまったということです。

拾聞：つまり、問題はコードがAIから来ているわけではなく、信頼の基盤が追いついていないということですね？

永亮：そう理解できます。そして、さらに言いたいことがあります：経験豊富なエンジニアほど、この不安を抱きやすいです。なぜなら、検証されていない詳細を知っていても、実際の環境ではどれだけ大きな問題になるかを知っているからです。新人はその負担を感じにくいことがあります。時には悪いことではありませんが、リスクも高いです。

Q2：個人的にそのブラックボックスとどう向き合っていますか？

拾聞：個人的な話です。17年間の技術経験を活かして、今でもコードを一行ずつ書いていますか？

永亮：まず自分に問います：このコードの「所有権」は誰のものか。私のものなら理解しなければならないし、AIのものなら確認しなければなりません。これは経験であり、統計ではありません。具体的な方法は三層に分かれています。第一層では、AIが関数を補う、正規表現を書く、テストデータを生成するなどを行い、入力と出力の意味的なずれがないことを確認してから使用します。第二層では、AIが並行処理、セキュリティ、状態機械に関するコードを提供した場合、その部分を一つ一つ説明させ、自分で境界ケースを実行します。第三層では、このコードが核心プロセスに入る場合、同僚が提出したPRのように扱います。自分で再読み、テストを追加し、レビューを行います。AIが「いい」と言ったからといってそのまま使うわけにはいきません。

拾闻：では、AIに触らせないシナリオはありますか？

永亮：あります。二つあります。一つ目は資金、権限、プライバシーに関わるコードで、例えば支払い検証、認証ロジック、データの匿名化などです。これらの分野は規則が厳しく、結果も重大です。AIが誤解を抱けば事故になる可能性があります。二つ目は自分でも明確に考えていないアーキテクチャの決定です。何をするかさえ明確に考えていないのに、AIにコードを書かせるのは、彼らに考えさせることに等しく、最終的に届くものは美しいが誤ったものになるでしょう。

拾闻：つまり、あなたの基準は「手書きでなくてもいいが、理解できないことはできない」ということですね。

永亮：そうです。この原則はどんなツールにも当てはまります。Gitを使うか、IDEを使うか、AIを使うかは関係ありません。最終的に署名するのはあなたであり、責任はあなたにあります。AIは法廷に出ることができず、説明もできず、責任を負うこともできません。

Q3：70人チームで、どのようにレビューメカニズムを構築しましたか？

拾闻：個人からチームへと昇華します。70人を管理してきましたが、AIが生成したコードはチーム内でどのように流通しますか？

永亮：まず一つの厳格なルールを設けます：AIが生成したコードは、提出説明に必ず記載しなければなりません。これはAIを差別するためではなく、レビュー時にリスクポイントがどこにあるかを知るためです。私がチームを率いていた時、コードレビューには特別なチェック項目がありました。「この変更で、どの決定が人間によるもので、どの決定がツールによるものか？」提出者が答えられなければ、再読みに戻します。

拾闻：しかし、AIが生成するコードは多すぎます。すべてをレビューできるでしょうか？

永亮：不可能です。だからメカニズムによる階層化が必要です。当時は影響範囲に応じて三つのレベルを設けました。第一レベルは普通のモジュールのコード変更で、AI生成の割合が低いため、通常のレビューを行います。第二レベルは核心モジュールへの変更で、二人以上の人がレビューを行い、ユニットテストと統合テストも含まれます。第三レベルは影響範囲が最も大きく、資金や権限に関わる部分で、AIは補助のみで、直接コードを生成することはできません。最終的には人が一行一行手書きして署名します。これら三つのレベルの境界はチームのWikiに明確に記載されており、新人が入社する際にはこの項目を見るべきです。

拾闻：テストに関して特別な要求はありますか？

永亮：あります。AIが書いたコードのテストカバレッジは、手書きのものよりも一ランク高くなければなりません。これは罰ではなく、対策です。詳細が理解できないため、テストに行動の境界を守らせる必要があります。また、AIが書いたコードの重要なパスは、同じモデルで生成してはいけません。理由は前述のedwin0のコメントで明らかです：AIは同じ思考でコードとテストを書く可能性があり、最終的にバグが完全に隠される可能性があります。

拾闻：同僚の中にはこの方式に反対する人はいますか？

永亮：もちろんあります。AIが負担を増やすことではないかと言う人もいますが、AIの目的は効率を高めることではないでしょうか？私の回答はこうです：AIが高めるのは「書き出した」効率であり、「審査済み、テスト済み、運用可能」という効率ではありません。もし検証されていないコードを安易に使うと、後でのデバッグや修正にかかる時間が何倍にも増えることになります。私がチームを率いてきたこれまでの年月で、この理論は何度も検証されてきました。だからこそ、それをプロセスに取り入れることができるのです。

拾闻：コード以外に、ドキュメントや週報、設計稿などはどうですか？

永亮：同じ理屈です。AIは説明を明確にする手助けにはなりますが、責任を代わりに負うことはできません。ドキュメント内の各判断や選択は、必ず具体的な人が背後にいる必要があります。私たちではこれを「署名制」と呼んでいます：誰の意見か、誰が署名するか；AIが作成したものも、最終的には人の確認を経てから公開されます。この規則は形式主義的に見えるかもしれませんが、「責任」という概念を具体的にしています。

Q4：反対意見はどう言っており、境界線はどこですか？

拾闻：HN上には反対や補足の声がたくさんあります。代表的ないくつかを紹介します。

永亮：事実ベースで高評価の意見を引用します。第一にspacedcowboyからのもので、要約するとこうです：動作すれば受け入れられます。まるで私が同僚が書いたすべてのコード行をチェックしないように。しかし、多くのテストや実際のプログラムをガードとして使用します。これには非常に同意します。AI生成のコードを適切な位置に置いています：一行一行を理解する必要はありませんが、可観測的な検証手段が必要です。

拾闻：これに対する反論は何ですか？

永亮：第二にedwin0からのものです。AIがコードとテストを同時に行うのは不安です。なぜなら、両方とも同じ間違いを犯す可能性があるからです。この警告は非常に重要です。コードとテストが同じモデルによって生成される場合、テストは「自己証明予言」になりやすいです。モデルが自分の考えでコードを書き、同じ考えでテストも書くと、テストは通るかもしれませんが、バグも隠されてしまいます。ですから、私たちの方法ではAIがコードを書くことは許されますが、重要なテストは人が行うか、別の方法で交差検証を行う必要があります。

拾闻：他にアプローチはありますか？

永亮：第三にmattbrewsbytesからの比喩です。これは実際には「概念の圧縮」であり、RailsのORMのようなものです。ほとんどの場合、これはうまく機能しますが、データベースの規模が大きくなると、SQLに戻らなければなりません。言い換えれば、AI生成のコードは一層の抽象化に基づいています。抽象化は実行を助けますが、限界に達すると、さらに深く掘り下げる必要があります。この比喩は私もよく使っています。これは私たちに警告を与えてくれます：AIが便利だからといって、基礎原理を忘れてはいけません。

拾闻：第四番目はどうですか？

永亮：billyloの意見はより工程実践的です：実行時の可観測性、交差検証、警告を通じてリスクを分散します。これは実際には私たちのチームメカニズムの別の表現です。すべてのブラックボックスリスクを事前に排除することはできませんが、問題が発生したときにすぐに発見できるようにすることができます。

拾闻：では、境界線はどこですか？

永亮：境界線は「可検証性」です。もしモジュールの入力と出力が明確にテストでき、ログや監視でカバーでき、同僚のレビューでカバーできるなら、ブラックボックスは問題ありません。しかし、それが検証できず、責任を問われず、監査されない場合、AIが書いたかどうかにかかわらず、直接運用すべきではありません。この境界線はAIとは関係なく、工程の素養に関係しています。

結語：ブラックボックスは消えないが、責任は移譲できない

拾聞：最後にまとめを述べます。今回の記事に一言でまとめてください。

永亮：AIがコードを書く際のブラックボックスへの不安は、本質的には責任の再分配です。以前は「あなたが書いたかどうか」に責任が置かれていましたが、今は「理解しているか、チェックしているか、責任を持てるか」に変わっています。ツールが強力になるほど、人間の判断の価値が高まります。ブラックボックスは消えないが、テスト、レビュー、監視、署名メカニズムを通じて、ブラックボックスを耐えられるものにすることができます。

拾聞：もう少し具体的に言うと、普通のエンジニアは今日何を持ち帰ることができるのか？

永亮：三つの点です。第一に、AIはあなたの副操縦士になるかもしれませんが、運転免許はあなた自身です。第二に、理解できないコードは、理解するか、十分なテストと監視を行うか、ブラックボックスを無防備にさせないようにしてください。第三に、生産環境に入るすべてのコードには、最終的に実際の人間が責任を持つ必要があります。技術がどのように変わろうとも、これは変わりません。次にAIがコードを書いてくれた後、急いで送信するのではなく、まず自分自身に問いかけてください：もしこのコードが明日問題を起こしたら、なぜこのように書かれているのか説明できるか？

情報源

• Hacker Newsの議論スレッド、2026-10-19、「Ask HN」：MetaのエンジニアAli Hamieは「最近コードを書いていると、すべてがブラックボックスのように感じられる…高いレベルは理解できるが、すべての詳細はわからない。そして、これが新しい標準になっているかもしれない。」と述べています（事実は引用であり、直接の引用です）。
• HNの高評価コメント spacedcowboy：「うまくいけば問題ない。同僚が書いたすべてのコード行をチェックするわけではないが、テストと実際のプログラムを重要な要素としている。」（事実は要約引用です）。
• HNの高評価コメント edwin0：「AIがコードとテストを同時に書くことは、同じミスを共有する可能性があるため、より不安だ。」（事実は要約引用です）。
• HNの高評価コメント mattbrewsbytes：概念はRails ORMに似ています。抽象層はほとんどの場合機能しますが、データベースの規模が大きくなるとSQLに戻る必要があります（事実は要約引用です）。
• HNの高評価コメント billylo：実行時の可観測性、交差検証、警告を通じてリスクをヘッジします（事実は要約引用です）。
• ゲストの経験：17年間の技術経験を持ち、ピーク時には70人のチームでした。Code Reviewの署名制、AIコードのマークアップ、テストカバレッジのヘッジ、コアモジュールの二人によるレビューなどは、すべて個人的な実践です。