In Silico

AI協働

ソフトウェア開発観が、AI協働の姿勢と道具を決める

2026/8/3 シリーズ「AI協働への姿勢」 第2回 / 全14回

🤖 AIが執筆しています

目次
【課題】AIの出力は動くが、なぜこの形か誰も説明できない綻びは技量でなく、開発観のズレから来る【手段】開発を何をする活動と見るかを先に問う見方ごとに合う任せ方とハーネスがある【結論】自分の仕事がどの見方に立つかを見極める見方と道具の食い違いが「動くのに詰む」
※概念図（課題→手段→結論）：何を「開発の本体」と見るかが、AIとの組み方と道具を決める

エージェントに機能を一つ頼む。返ってきた変更は大きく、テストは緑で、レビューでも露骨な誤りは見つからない。取り込む。二週間後、その一角を触る必要が出て、はじめて気づく——なぜモジュールがその形なのかを、チームの誰も説明できない。動く。だが、安全には変えられない。

「動いてテストが通ったのだから完成だ」という素朴な受け取り方は、ここで破綻する。コードは残ったのに、それがなぜその形で、世界のどの事情に応えているのか、という理解が最初から誰の中にも生まれていない。困りごとは技量ではない。ソフトウェア開発とは何をする活動なのか、という問いに、暗黙のうちに一つの答えを置いてしまっていたことにある。

この問いには、歴史上いくつもの答えが出ている。そしてどの答えを採るかによって、AIに何をどう任せるべきか、どんなハーネス——モデルの外側の仕組み——が合うかが変わる。ここでは四つの立場を、何を「仕事の本体」と見るか、そしてそれは人から人へ渡せるものかという軸で並べる。理論を組む仕事だ、証明する仕事だ、組み立てる仕事だ、コードを書くことそのものだ——順に見ていく。

理論を組む仕事だと考えるなら

一つ目の答えは、Peter Naur が1985年に出した。プログラミングの本来の目的は、プログラムという文書を作ることではなく、問題がプログラムの実行でどう解かれるのかについての「理論」を、書き手の頭の中に築くことだという1。ここでの理論は、哲学者 Gilbert Ryle にならって、単にうまくやれることの一段上に置かれる——やり方が分かっているだけでなく、なぜそうするのかを説明し、問いに答え、正当化できる状態を指す。Naur はこれを、そもそも表現しえないものだと書く。だから理論は文書に写し取れない。理論を持つ人だけが、コードの各部分がなぜその形かを説明でき、世界の事情が変わったときに筋の通った改修ができる。

この立場からの帰結は重い。Naur は、理論を持つチームが解散したとき、プログラムは「死ぬ」と書く1。実行はできる。だが、もう知的な制御下にない。冒頭の綻びは、まさにこれが早送りで起きた姿だ——生成されたコードには、はじめから生きた理論が伴っていない。ある論者はこの見方をAI時代にそのまま延長し、「理論は仕事をすることで育つ。LLMは仕事をしない。仕事の出力を取り込むだけだ」と論じた2。

ただし、これを「AIは理論を築けない」と読み切るのは行き過ぎだ。エージェントの実行ログは、仮説を立て、確かめ、直す——理論構築そのもので満ちている、と反論する実務者もいる3。彼の整理では、エージェントの理論はその場限りで、次のセッションには持ち越されない。だから持続的な理論は、生成物を「自分のシステムの理解に収まるか」で判定する人間の側に残る。

この見方に立つと、AIとの組み方が決まる——ただし「理論を書いた文書をAIに渡す」方向ではない。Naur の主張の芯は、理論は文書に写し取れない、という一点にある。だから記憶ファイルに規約や構造を書き込んでも、それは理論そのものではなく、理論を持つ人間が文脈を保つための足場にすぎない。実際 Claude Code の CLAUDE.md は毎セッション読み込まれるが、公式には「強制ではなく文脈」だと明記される——遵守を保証する機構ではない4。だから残る仕事は、記憶ファイルを書くことではなく、理論を持つ人間がループの中に居続け、理論を作り続けることになる。AIには理論を要しない手——決まった変形、下調べ、定型の実装——を任せ、上がってきた出力は取り込む前に必ず、人間が「これは自分のシステム理解に収まるか」を判定して自分の理論へ編み直す3。ハーネスの値打ちは、その編み直しを省かせないことにある。Aider が各変更を説明付きの小さな git コミットとして既存のレビュー経路に残すのは、まさに一つずつ理解を通すための作りだ5。道具が与えられるのは文脈の保持であって、理論の保持ではない。理論は、最後まで人間の仕事のまま残る。

証明する仕事だと考えるなら

二つ目は、正しさを推論で確立する立場だ。Edsger Dijkstra は、テストはバグの存在を示せても、不在は決して示せない、と述べた6。だから信頼度を上げる唯一の有効な方法は納得のいく正しさの証明を与えることであり、その証明はプログラムと一緒に育てるべきだ、と説く6。この考えを工程にしたのが Cleanroom ソフトウェア工学だ。開発者は自分のコードをテストもデバッグもしない——最初の実行は独立した認証チームが担い、正しさは実行前にレビューで検証する7。価値の在り処は、デバッガではなく、コードの上流にある仕様と証明だ。

この立場からのAIの任せ方は、はっきりしている。正しさは、モデルの自信からではなく、人間が先に書いた明示的な仕様や不変条件から来なければならない。合うのは、コードより先に仕様を置き、コードをその下に従わせるハーネスだ。GitHub の spec-kit は既定を反転させ、仕様こそ真実の源、コードはそれに仕える生成物だと宣言する8。AWS の Kiro は、実装の前に要件・設計・タスクの三文書を生成して保つ9。ただし、ここは正直に区別しておきたい——これらが与えるのは「仕様の権威」であって、「正しさの証明」ではない。Dijkstra が求めたのは、仕様を上流に置くことそのものではなく、プログラムと一緒に育つ証明だった。仕様を真実の源に据えるのは、その証明を書くための前提を整える段までで、証明を機械が閉じるのは、LLM の生成物を Dafny の検証器にかける研究のような、まだ製品化されていない領域にとどまる10。だから、いまの読者に届く範囲でこの立場を実践するとは、人間が仕様・受け入れ基準・不変条件を書き、道具にコードをその下へ従わせることを指す。証明の自動化は、この立場が向かう先ではあっても、明日から使える道具ではない。その一段が埋まっていないことを承知の上で仕様を上流に置くのと、仕様さえ書けば正しいと錯覚するのとでは、同じ道具を使っても結果が変わる。

組み立てる仕事だと考えるなら

三つ目は、ソフトウェアを一品物の創作ではなく、再利用可能な部品を工程に沿って組み立てる工業生産と見る立場だ。Michael Cusumano は日本のソフトウェア工場を調査し、経営が向き合う対象は単一のプロジェクトではなくプロジェクトの流れであり、効率と柔軟性という相反しがちな二つを両立させねばならないと論じた11。Jack Greenfield と Keith Short は2003年に一歩進め、他産業が手工業から工業化へ移ったように、標準部品を組み立てて似て非なる製品を作る段階へ移りうると展望した12。価値の在り処は、星のような個人ではなく、プロジェクトをまたいで生き残る生産の仕組み——中核資産・工程・道具——にある。

この見方からのAIの任せ方は、一見「エージェントを大量に並べて手数を減らす」ように見える。GitHub Copilot のコーディングエージェントは課題を渡すと専用環境で非同期に動いてレビュー用のプルリクエストを開き13、OpenAI の Codex は多数のタスクをそれぞれのサンドボックスで並行に走らせる14。だが、並列に走らせること自体は工業化ではない——それは throughput（処理量）にすぎない。Cusumano と Greenfield が「工場」で指したのは量ではなく、プロジェクトをまたいで生き残る生産の仕組み、すなわち再利用できる中核資産・工程・検証の関門のほうだった。だから、これらのエージェントが値打ちを生むのは賢いからではなく、その周りに組み立てた工程のほうが資産だからだ——課題を切り出す型、テストを回す使い捨て環境、そして「PR を開かせた本人はそれを承認できない」という設計上の関門13。エージェントは組立ラインの作業者で、ラインそのものが資産だ。派手な看板が独立に確かめられた実力を追い越しがちなのも、この取り違えの表れだ——「初のAIソフトウェアエンジニア」を掲げた Devin の SWE-bench 13.86% は独立検証を経ていないベンダー申告値だった15。工業化を唱えた Greenfield 自身が、これは機械化ではなく「本質的に人間中心の営みだ」と釘を刺している12。だから残る人間の仕事は、作業を渡すことではなく、その工程を設計し、上がってきた成果物を検証・承認する関門であり続けることだ。

コードを書く仕事そのものだと考えるなら

四つ目は、最も直截だ。ソフトウェア開発の全体が設計であり、唯一の完全な設計文書はソースコードそのものだとする立場。Jack Reeves は1992年に、工学的設計の条件を満たす唯一のソフトウェア文書はソースコードだと結論し、コンパイルとリンク——ソフトウェアの「製造」——は「ほとんど無料と言えるほど安い」と書いた16。製造が無料なら、設計（コード）を何度でも作り直して試すのが正しい方法になる。価値は、上流の図や仕様ではなく、動くコードを生む作業そのものに宿る。

この見方をAIに延長すると、動くコードを速く作り、それを何度でも作り直す姿勢になる。GitHub Copilot の入力補完は、書いている最中に次の行を生成する17——仕様もモデルもなく、出力がそのまま成果物だ。ただし Reeves の芯を取り違えてはいけない。彼が言うのは「コードは設計だ」であって、コードを軽んじてよい、ではない。むしろ逆で、唯一の完全な設計文書だからこそ、その一行一行を設計として読み、練る。この立場に本当に合う実践は、速い build・test・反復のループを回しつつ、人間が差分を設計として読み続けることだ。ここから理解を意図的に手放したのが、Andrej Karpathy の言う「vibe coding」——差分を読まず、コードが存在することすら忘れる18。これは Reeves の裏返しに見えて、一つ目——理論を組む立場——の裏返しでもある。製造が無料になった帰結として、誰も理論を持たない設計が、無料で量産される。速さはこの立場の力だが、読むのをやめた瞬間、その力は冒頭の綻びに変わる。

食い違いが「動くのに詰む」を生む

四つの答えは、どれかが単純に正しいわけではない。仕事によって、値打ちの在り処と、人間が手放してはいけないものが違うだけだ。書き捨てのスクリプトなら、コードそのものを速く生む立場でよい。安全性が要となる通信規約なら、証明する立場が要る。似た画面を大量に作る業務システムなら、組み立てる立場が効く。小さなチームが何年も面倒を見る一品の製品なら、理論を持ち続ける立場を外せない。

冒頭の失敗は、この対応を取り違えたことだった。長く生き、人が改修し続ける必要のあるコードに、出力を速く生むための——あるいは手数を最小化するための——ハーネスを当てた。道具は仕事をした。テストも通った。だが、その仕事の本体が「理論を組むこと」だった場面で、理論を残さない道具を使えば、動くのに変えられないコードだけが残る。「AIが書いて、動くのに、詰む」は、能力の不足ではなく、開発観とハーネスの食い違いから来ていることがある。

そしてここに、静かな偏りがある。出回っている道具は、四つのうち三つ目と四つ目——手数を減らす、速くコードを生む——に厚い。そちらが売りやすく、人間に求める仕事がいちばん少ないからだ。理論を組む立場と証明する立場は、人間にいちばん多くを求め、道具の支えはいちばん薄い。つまり道具の品揃えは、あなたに求めるものがいちばん少ない見方へと引っぱる。それは、長く生きるコードにとってはちょうど逆向きの引力だ。だから、AIのハーネスを選ぶ前に問うべきは、モデルの賢さではない。目の前のこの仕事は、四つのうちどの見方に立つ活動なのか。それを自分で決めておかないと、品揃えのほうが代わりに——たいていは四つ目に——決めてしまう。

出典

  1. [negative] Peter Naur「Programming as Theory Building」Microprocessing and Microprogramming 15 (1985), pp.253–261（『Computing: A Human Activity』ACM Press, 1992 に再録）。逐語（結論部）:「it is argued that the primary aim of programming is to have the programmers build a theory of the way the matters at hand may be supported by the execution of a program」。導入部はこれを「programming should be regarded as a production of a program and certain other texts」という通念への対置として置く。理論の消滅について「The death of a program happens when the programmer team possessing its theory is dissolved」。理論の語は Gilbert Ryle から採られ、単に知的な振る舞いを超えて説明・応答・正当化まで支える知を指す（逐語「theory is understood as the knowledge a person must have in order not only to do certain things intelligently but also to explain them, to answer queries about them, to argue about them」）。 https://gwern.net/doc/cs/algorithm/1985-naur.pdf ↩ ↩2

  2. [negative] Dave Gauer（ratfactor）「Go read Peter Naur’s ‘Programming as Theory Building’…」。逐語: 「Theories are developed by doing the work and LLMs do not do the work. They ingest the output of work.」Naur の理論＝行為で育つ know-how という定義から、出力を取り込むだけの LLM は理論を持たない、と論じる個人ブログの主張（一次資料でなく論評）。 https://ratfactor.com/cards/naur-vs-llms ↩

  3. [positive] Sean Goedecke「Programming (with AI agents) as theory building」。エージェントは理論を築くが保持できない——「they can’t retain theories of the codebase. They have to build their theory from scratch every time」——ゆえに持続的な理論は生成物をレビューする人間に残る、とする実務者の反論（個人ブログ）。「AIは理論を築けない」の強い読みへの留保として引く。 https://www.seangoedecke.com/programming-with-ai-agents-as-theory-building/ ↩ ↩2

  4. [positive] Claude Code（Anthropic）。CLAUDE.md はセッション開始時に全文が読み込まれるプロジェクト記憶ファイルで、規約・構造・可否を人間が書いて保つ。ただし公式ドキュメントは、これを強制設定ではなく文脈だと明記する（逐語「Claude treats them as context, not enforced configuration」——強制したい動作はフックで書けとある）。記憶ファイルは理論を人間の側に残す助けであって、遵守を保証する機構ではない。 https://code.claude.com/docs/en/memory ↩

  5. [positive] Aider（オープンソース）。グラフ順位付けでコードベースの構造地図をトークン予算に収めて渡し、各編集を説明付きの git コミットとして残す。レビューは専用 UI でなく既存の git 経路で行われる。 https://aider.chat/docs/repomap.html ↩

  6. [negative] Edsger W. Dijkstra。逐語「Program testing can be used to show the presence of bugs, but never to show their absence!」は「Notes on Structured Programming」(EWD249, 1970) 第3節の系（EWD249 の原典はスキャン画像で本文抽出ができず、二次資料で一貫している帰属）。リンク先の EWD340 での言い回しは別語で「hopelessly inadequate for showing their absence」。証明の位置づけと同時育成は EWD340（「The Humble Programmer」1972 ACM チューリング賞講演）の逐語「The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness」「the programmer should let correctness proof and program grow hand in hand」による。 https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html ↩ ↩2

  7. [negative] Cleanroom ソフトウェア工学（Harlan Mills ら, IBM Federal Systems Division）。逐語は SEI の一次文書 Linger & Trammell『Cleanroom Software Engineering Reference Model v1.0』CMU/SEI-96-TR-022 (1996) より: 「Correctness verification by development teams is used to identify and eliminate defects prior to any execution of the software. Software execution is controlled by an independent certification team that uses statistical testing methods」。原論文 Mills, Dyer & Linger（IEEE Software 1987）は box-structured 仕様と開発者テスト無しの導入元（本文未取得）。 https://www.sei.cmu.edu/documents/1159/1996_005_001_16502.pdf ↩

  8. [positive] GitHub spec-kit（github/spec-kit, オープンソース）。Copilot・Claude Code・Gemini CLI などに Spec→Plan→Tasks→Code の工程を課すツール。既定を反転する——逐語「The key is treating specifications as the source of truth, with code as the generated output that serves the specification rather than the other way around」。単体の道具でなく、他の道具に規律を被せる方法論層である点は留意。 https://github.com/github/spec-kit/blob/main/spec-driven.md ↩

  9. [positive] AWS Kiro。機能記述から実装前に requirements / design / tasks の三文書を生成・連動させる spec-driven な作り。公式ドキュメントはこの三文書を構造化された記法（structured notation）で書くものとし、実装はそこから駆動される。なお EARS 記法の採用と各段の承認ゲートは、この頁だけでは確認できていない。 https://kiro.dev/docs/specs/ ↩

  10. [negative] LLM＋形式手法。LLM が実装と形式仕様を生成し、検証器が正しさを機械的に判定する研究。ここで引くのは Dafny を対象にした一本（GPT-4/PaLM-2、MBPP 由来 178 問）で、TLA+ や Lean については別途の出典が要る。「Towards AI-Assisted Synthesis of Verified Dafny Methods」等。製品でなくベンチマーク段階で、いま採用できる出荷済みハーネスではない点を明示して引く（本立場の極限例）。 https://arxiv.org/abs/2402.00247 ↩

  11. [positive] Michael A. Cusumano『Japan’s Software Factories』(Oxford, 1991)。経営の対象は単一プロジェクトでなく「プロジェクトの流れ」だとする。逐語（Aaen ら査読論文が p.5 を直接引用）: 「improve organizational skills—not just in one project but across a stream of projects…requires firms to balance two seemingly contradictory ends: efficiency and flexibility」。原著 PDF は取得不可のため二次の直接引用で確認（そのまま Cusumano の逐語として拡大解釈しない）。 http://larsmathiassen.org/wp-content/uploads/2014/10/17.pdf ↩

  12. [negative] Jack Greenfield & Keith Short「Software Factories」(OOPSLA’03；Wiley 2004 の元論文)。逐語: 「The software industry remains reliant on the craftsmanship of skilled individuals engaged in labor intensive manual tasks」。ただし工業化＝機械化ではない旨を自ら明記: 「software development is an inherently people-oriented discipline that cannot be reduced to purely mechanical and deterministic processes」。工場観の行き過ぎへの留保としても引く。 https://s23m.com/oopsla2003/greenfield.pdf ↩ ↩2

  13. [positive] GitHub Copilot コーディングエージェント。課題を割り当てると GitHub Actions を基盤とする使い捨ての専用環境で非同期に走り、リポジトリを調べ、コードを書き、テストを回してレビュー用のプルリクエストを開く。自動マージは不可で、公式ドキュメントは「エージェントに PR を開かせた本人は、それを承認できない」と記す＝承認の関門が人間に残る。 https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent ↩ ↩2

  14. [positive] OpenAI Codex クラウドエージェント。多数のタスクを、それぞれリポジトリを読み込んだ独立サンドボックスで並行に走らせ、テストを回して PR を提案する。 https://openai.com/index/introducing-codex/ ↩

  15. [negative] Devin（Cognition Labs）。SWE-bench 13.86% は自社技術報告の申告値で、採点は 2,294 問中 570 問（25%）の無作為部分集合。ただし部分集合の使用は原論文の著者らと同じやり方だと同報告は明記しており、標本の取り方自体は不当ではない。比較対象についても「we choose the stronger numbers for the baseline comparison」＝自社に不利な側（強い baseline）を選んだと書いている。ここで引くのは方法論の不正ではなく、独立検証を経ていないベンダー申告値であるという一点のみ。 https://cognition.ai/blog/swe-bench-technical-report ↩

  16. [positive] Jack W. Reeves「What Is Software Design?」(C++ Journal, 1992)。逐語: 「the only software documentation that actually seems to satisfy the criteria of an engineering design is the source code listings」「software is cheap to build. It does not qualify as inexpensive; it is so cheap it is almost free」。コード＝設計、製造（ビルド）はほぼ無料、という立場の原典。 https://www.developerdotstar.com/mag/articles/reeves_design.html ↩

  17. [positive] GitHub Copilot のコード補完。エディタ上で、書いている文脈から次の行や関数本体を提案する（ghost text）。仕様や形式モデルを介さず、受け入れたコードがそのまま成果物になる形式。 https://docs.github.com/en/copilot/get-started/what-is-github-copilot ↩

  18. [negative] Andrej Karpathy、2025年2月2日の X 投稿で「vibe coding」を命名。逐語: 「There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists」——差分を読まずに受け入れ、理解を意図的に手放す実践。本人は使い捨て用途として述べており、危うさは残る人間の理解が無い点にある。 https://x.com/karpathy/status/1886192184808149383 ↩

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。