AIが書いたコードは「ブラックボックス」でいい？　Claude Code作者が語るプロトタイプと本番の線引き：Deep Insider Brief ― 技術の“今”にひと言コメント

Claude Codeの作者ボリス・チャーニー氏が、「AIが書いたコードは中身を見なくてよいのか」という開発者からの相談に回答した。プロトタイプと本番コードの線引きと、品質を守るための具体策を、筆者自身の実践も添えて紹介する。

» 2026年09月29日 05時00分公開

[一色政彦，デジタルアドバンテージ]

この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。

　AIが書いたコードは、人間がきちんと読んで理解すべきなのか。それとも、正しく動きさえすれば「ブラックボックス」のままでよいのか。AIコーディングを実務で使い始めると、一度は考える問いではないだろうか。

　AIコーディングツール「Claude Code」の作者であるAnthropicのボリス・チャーニー（Boris Cherny）氏は2026年9月11日、まさにこの悩みを抱える開発者から届いた相談メールと、自身の回答をXで公開した。チャーニー氏によれば、こうした相談は「毎日たくさん届く」という。では、Claude Codeを作った本人は、AI生成コードとどう付き合うべきだと考えているのだろうか。

AIが書いたコードを「ブラックボックス」として扱えるのは、どこまでか。プロトタイプと本番コードの線引きをイメージしたイラスト（本記事オリジナル）

　相談者は、ある企業に12年間勤める開発者だ。職場ではAIエージェント型開発への移行を巡り、「AI生成コードも人間が理解・説明できる状態にしておくべき」という考えと、「コード内部はブラックボックスとして、出力だけ確認すればよい」という考えに意見が分かれているという。AIにコードを生成させること自体は速い一方、AIが選んだ方針が本当に妥当なのかを見極める方に時間がかかることもあり、どう考えればよいのかとチャーニー氏に尋ねた。

　チャーニー氏の答えは、「どちらにも適した場面がある（there is room for both）」というものだった。プロトタイプや使い捨てのコードで、壊れても影響範囲が小さいなら、完全なブラックボックスとして扱って構わない。一方、Claudeが書く本番コードには、むしろ人間が書いたコードより高い品質基準を課すべきだという。

　そのためAnthropicでは、Lint（コードの書き方を自動で指摘するツール）や各種テスト、自動コードレビューなど、数多くのガードレール（品質を守る仕組み）を用意しているという。そしてチャーニー氏は、開発者の役割を端的にこう表現している。「あなたの仕事は、コード品質の基準を守ることだ（Your job is to hold the bar on code quality）」と。

――ここからは『Deep Insider Brief』恒例の“ひと言コメント”として筆者の考えを述べた上で、チャーニー氏の回答やリプライ欄で示された論点を、もう少し詳しく整理していく。

　Deep Insider編集長の一色です。こんにちは。

　今回の相談は、私にとってもかなり身近な問題です。私の周囲にも「AIに書かせたコードを人間が読むことに時間を使うのは、効率が悪いのではないか」という考え方があります。

　私自身も、データ分析用のプロトタイプなどでは、AIが生成したコードを基本的に全て読むことはありません。ただし、完全なブラックボックスにもしていません。どのような処理が書かれているかを大まかに想像できる状態は保ち、動作がおかしいときや気になる部分があれば、AIに実装を説明させたり、実際のコードを確認したりします。

　特に重要だと思っているのが、テストそのものを信用し過ぎないことです。例えばexpect(true).toBe(true)のように、実装を何も検証せず必ず成功するテストを、AIが生成してしまうこともあり得るからです。私も最近、全件Passしていたテスト群の中に、実装が壊れても失敗しないテストが含まれていた、という話を目にしました。

　だから私は、形だけのテストが混ざっていないかをAIにもチェックさせています。その上で、AIにコードを任せる範囲が広がるほど、「ガードレールそのものが本当に機能しているか」も人間が時々確かめる必要があると考えています。例えば、コードを全行読む代わりに、あえて実装を壊し、テストが本当に失敗するかを抜き打ちで確認するといった方法です。

　もう一つ続けているのが、ファイル構成や命名を整理し、仕様を文書として最新の状態に保つことです。チャーニー氏の言う「品質の基準を守る」を個人や小規模な開発で実践するなら、私はまず「信頼できるテスト」と「整理された構造と仕様」の2つから始めるのが現実的だと思っています。

　筆者の実践はあくまで小規模開発での話だ。ここからは、チャーニー氏がAnthropicでの実践を交えながら示した考え方を、順に整理していく。

チャーニー氏の回答を3つのステップで整理する

　チャーニー氏の回答は、大きく3つのステップに分けると分かりやすい。「どのコードならブラックボックスとして扱えるか」を判断し、本番コードには「品質を守る仕組み」を設け、それでも基準に届かないときの「対処法」を持つ、という流れだ。

ステップ1：コードの用途で線引きする

プロトタイプ（試作品）や使い捨てのコード： 完全なブラックボックスとして扱ってよい。いずれ捨てるものであり、壊れても影響範囲が小さいなら、完璧である必要はない
本番コード（実際のサービスや業務で使い続けるコード）： Claudeが書いたものには、人間が書いた場合より高い基準を課す。守る仕組みがないと、後から保守が難しい状態になりかねない

　つまり「読むか読まないか」を一律に決めるのではなく、まずコードの用途や、壊れたときの影響を考えるということだ。

ステップ2：本番コードは「仕組み」で品質を守る

　チャーニー氏は、本番コードに求める高い基準を支えるガードレールとして、Anthropic社内で使われている次のような仕組みを挙げている。

書き方のチェック： Lint（リント：コードの書き方の問題を自動で指摘するツール）のルールを多数用意する
動作のチェック： 多数のテストに加え、Claudeが実行するE2Eテスト（利用者の操作を最初から最後まで通して確認するテスト）や、Claudeを使ったファザー（fuzzer：ランダムな入力を大量に与えて不具合を探すツール）を毎日回す
レビューのチェック： コードレビューとセキュリティレビューを自動化する
構造の維持： リファクタリング（動作を変えずに内部構造を整理する作業）も自動化する

　チャーニー氏は、Claudeのモデル性能が向上するにつれて、こうした品質管理の自動化も行いやすくなっているとし、日次のルーティン（毎日実行する処理）を幾つか自動で回したり、Claude Code Reviewを利用したりする方法を挙げている。

ステップ3：品質が足りないときの対処法

　それでもClaudeのコードが基準に届かない場合、チャーニー氏は次の3つを試すよう勧めている。

最新のフロンティアモデル（最先端の高性能モデル。原文ではOpus 5またはFable 5.1）を使う
effort（AIがどれだけ深く考えるかの設定）をhighまたはxhighに上げる
CLAUDE.md（プロジェクトのルールをClaudeに教える設定ファイル）やスキル（作業手順をまとめた指示ファイル）を充実させ、自分のコードベースでの作業方法を簡潔に教える

　それでも駄目なら、作業中にClaudeをより細かく誘導するか、Claudeに蓄積した技術的負債（後回しにしてきた設計上の問題など）を解消させ、作業しやすいコードベースへ書き直させる。あるいは、より性能の高い次のモデルが登場するのを待つ、という選択肢もある。

リプライ欄での補足

　このポストには多くのリプライが付いた。線引きの考え方を補強するものを2つ拾っておく。

影響範囲で決める： レビューの厳しさは「誰が書いたか」ではなく「壊れたときの影響範囲」で決めるべきだ。使い捨てのスクリプトはそのまま出すが、金銭やログインに関わるコードは今も全行自分で読む、という意見に、チャーニー氏は「Exactly（その通り）」と同意した
これから学ぶ人はどうなるか： 「手でコードを書いた経験やレビュー能力がないまま卒業する人はどうなるのか」と問われ、チャーニー氏は「コーディングは自動化されたが、システム設計やコードレビューなどはまだ完全には自動化されていない」と回答した。今後6～12カ月は、学校で学ぶ一部のエンジニアリングスキルがソフトウェアを書く人にとって重要であり続けるが、その後は幾何学や歴史のように、毎日は使わなくても考え方の枠組みとして役立つ「背景知識」になっていくだろう、と述べた