AI協働

ソフトウェア開発とは何をする仕事か：4つの見方とAIに任せる範囲

2026/8/3 （更新: 2026/11/3）

🤖 AIを使用して執筆

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

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

理論を持つ人がいなくなると、プログラムは改修できなくなる。Naur は、理論を持つチームが解散したとき、プログラムは「死ぬ」と書く¹。実行はできる。だが、もう知的な制御下にない。背景で取り込んだ差分は、チームが解散する前から、取り込んだ時点で同じ状態になっている。差分がなぜその形なのかを説明できる理論が、チームの誰の中にも生まれていないからだ。

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

この見方では、理論を書いた文書をAIに渡しても、理論は渡らない。Naur の主張の中心は、理論は文書に写し取れない、という一点にある。だから記憶ファイルに規約や構造を書き込んでも、それは理論そのものではない。理論を持つ人間が、モデルに毎回読ませる入力（コンテキスト）を整えるための材料である。実際 Claude Code は上位階層の CLAUDE.md を毎セッション読み込む。だが公式ドキュメントは、これを「強制ではなくコンテキスト」だと明記する。遵守を保証する機構ではない³。

だから残る仕事は、記憶ファイルを書くことではなく、理論を持つ人間が出力を一つずつ判定し、理論を作り続けることになる。先に引いた実務者は、自分の運用をこう書く。二つか三つのエージェントに問いの調査やコードの実装を並行して任せ、上がってきた出力が自分のシステム理解に収まるかをまず判定する。収まらない出力はおよそ8割で、その場で止めるか差し戻す。残りは自分でコードベースを当たり、手で試して確かめ、最終的に自分の成果へ入るのは出力の1割ほどだという²。ハーネスの値打ちは、その判定と確かめ直しを省かせないことにある。

Aider は、読む対象を用意するハーネスの例である。Aider は各変更を、説明付きの小さな git コミットとして既存のレビュー経路に残す。一つずつ理解を通すための作りだ⁴。ただし、その説明文を書いているのは人ではない。差分とチャット履歴を渡された別指定のモデルが生成する⁴。なぜその形なのかの答えは、記録の側からは出てこない。ツールが与えるのはコンテキストの保持であって、理論の保持ではない。

いまのところ、持続的な理論を持つのは人間である。ただしこれは現時点の工学的な制約であって、役割の固定ではない。先に引いた実務者自身が、エージェントの次の大きな進歩はおそらく理論を持ち越せるようにする仕組みだろう、と予想している²。

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

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

AIに任せるときも、正しさは、モデルの自信からではなく、人間が先に書いた明示的な仕様や不変条件から来なければならない。合うのは、コードより先に仕様を置き、コードをその下に従わせるハーネスだ。GitHub の spec-kit は既定を反転させ、仕様こそ真実の源、コードはそれに仕える生成物だと宣言する⁷。AWS の Kiro は、実装の前に要件・設計・タスクの三文書を生成して保つ⁸。

これらが与えるのは「仕様の権威」であって、「正しさの証明」ではない。Dijkstra が求めたのは、仕様を上流に置くことそのものではなく、プログラムと一緒に育つ証明だった。仕様を真実の源に据えるのは、その証明を書くための前提を整える段までだ。

証明を機械に任せる例として引いたのは、LLM の生成物を Dafny（仕様と証明を書くと検証器が検査するプログラミング言語）の検証器にかける研究で、製品ではなくベンチマーク段階のものだった⁹。だから、いまの読者に届く範囲でこの立場を実践するとは、人間が仕様・受け入れ基準・不変条件を書き、ツールにコードをその下へ従わせることを指す。証明の自動化は、この立場が向かう先ではあっても、本稿が当たった範囲に、明日から使えるツールは見当たらない。証明を自動化する道具が欠けていることを承知の上で仕様を上流に置くのと、仕様さえ書けば正しいと錯覚するのとでは、同じツールを使っても結果が変わる。

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

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

エージェントを並列に走らせるだけでは、この意味の工業化にならない。GitHub Copilot のコーディングエージェントは課題を渡すと専用環境で非同期に動いてレビュー用のプルリクエストを開き¹²、OpenAI の Codex は多数のタスクを、それぞれ外部から隔離した実行環境（サンドボックス）で並行に走らせる¹³。並列化が増やすのは throughput（処理量）である。Cusumano が挙げた工場実装の共通要素の一つは体系的な再利用性であり¹⁰、Greenfield が「工場」で指したのも量ではなく、体系的な再利用とそれを支える工程のほうだった¹¹。

検証の関門も、この工場観に元からある。Cusumano の共通要素には工程品質の分析と管理が並び、東芝のソフトウェア工場も1987年までに、設計レビューとインスペクション（決まった手順で成果物を人が読んで欠陥を探す検査）を標準化して管理する仕組みを施策に加えていた¹⁰。本稿はその関門を、エージェント時代の形に置き直して考える。したがって、これらのエージェントの値打ちを決めるのは賢さそのものより、その周りに組み立てた工程のほうで、工程こそが資産になる。工程とは、課題を切り出す型、テストを回す使い捨て環境、そして「PR を開かせた本人はそれを承認できない」という設計上の関門を指す¹²。エージェントは工程の中の作業を担い、資産として残るのは工程である。

宣伝の文句が、第三者の確かめた実力より先に出た例もある。「初のAIソフトウェアエンジニア」を掲げた Devin の SWE-bench 13.86% はベンダー申告値だった¹⁴。ただし Devin の技術報告は評価ハーネスと差分を公開しており、検証を拒む形ではない。欠けているのは第三者による再走の提示である。

工業化を唱えた Greenfield 自身、論文の出発点に「ソフトウェア開発は本質的に人間中心の営みであり、純粋に機械的・決定論的な工程には還元できない」を置いている。そのうえで、機械的・決定論的な部分はツールに渡す人間中心の工業化を提案する、という順序だ¹¹。だから人間の仕事は、作業を渡すことではなく、その工程を設計し、上がってきた成果物を検証・承認する関門であり続けることだ。

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

四つ目は、最も直截だ。ソフトウェア開発の全体が設計であり、設計文書と呼べるものはソースコードだけだとする立場。Jack Reeves は1992年に、工学的設計の条件を満たすと言えそうな唯一のソフトウェア文書はソースコードだと結論した。そして直後に、これは賛否両論を書き尽くせるほどの論点であり、自分の記事はそれを証明せずに前提として置くと自ら宣言している。その前提の上で、Reeves はソフトウェアの「製造」にあたるコンパイルとリンクを「ほとんど無料と言えるほど安い」と書いた¹⁵。製造が無料なら、設計（コード）を何度でも作り直して試すのが正しい方法になる。価値を生むのは、上流の図や仕様ではなく、動くコードを生む作業そのものである。

この見方をAIに延長すると、動くコードを速く作り、それを何度でも作り直す姿勢になる。GitHub Copilot の入力補完は、書いている最中にコードを提案する¹⁶。仕様も設計図もなく、出力がそのまま成果物だ。

ただし Reeves の主張は、コードを軽んじてよい、ではない。彼が言うのは「コードは設計だ」である。設計文書がコードしかないからこそ、その一行一行を設計として読み、練る。この立場に本当に合う実践は、速い build・test・反復のループを回しつつ、人間が差分を設計として読み続けることだ。ここから理解を意図的に手放したのが、Andrej Karpathy の言う「vibe coding」である。差分を読まず、コードが存在することすら忘れる（本人は使い捨てのプロジェクト向けとして述べている）¹⁷。vibe coding は、差分を設計として読む Reeves の実践を捨て、同時に、理論を組むという一つ目の立場の仕事も捨てている。

Reeves が無料だと書いたのは製造の側だけだ。設計のほうは途方もなく高くつく、と同じ論文が対句で続けている¹⁵。いま安くなったのは、その高くつくはずのほう、すなわちコードを書く行為そのものだ。だから、誰も理論を持たない設計が、はじめて量産できるようになった。速さはこの立場の力だが、読むのをやめると、その速さのまま、動くのに変えられないコードが増えていく。

四つの見方で、ツールに渡せる範囲

四つの立場のあいだには、正面からの衝突もある。Reeves は、ソフトは安く作れる以上、形式的な検証手法は実務では大して役に立たないと書いている¹⁵。テストは不在を示せないとする Dijkstra⁵ とは、ここでぶつかる。

そしてツールが肩代わりできる範囲は、四つの見方で同じではない。組み立てる立場と、速くコードを生む立場では、ツールが成果物そのものを出す。理論を組む立場と証明する立場では、ツールが渡すのは仕様の権威と下書きまでで、それを頭の中の理論に織り込む仕事も、その仕様が本当に欲しいものかを決める仕事も人間がする。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。