AI協働

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

2026/8/3 （更新: 2026/10/14）

🤖 AIを使用して執筆

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

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

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

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

この見方に立つと、AIとの組み方が決まる。ただし「理論を書いた文書をAIに渡す」方向ではない。Naur の主張の芯は、理論は文書に写し取れない、という一点にある。だから記憶ファイルに規約や構造を書き込んでも、それは理論そのものではない。理論を持つ人間がコンテキストを保つための足場である。実際 Claude Code は上位階層の CLAUDE.md を毎セッション読み込む。だが公式ドキュメントは、これを「強制ではなくコンテキスト」だと明記する。遵守を保証する機構ではない⁴。だから残る仕事は、記憶ファイルを書くことではなく、理論を持つ人間がループの中に居続け、理論を作り続けることになる。

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

Aider は各変更を、説明付きの小さな git コミットとして既存のレビュー経路に残す。一つずつ理解を通すための作りだ⁵。ただし、その説明文を書いているのは人ではない。差分とチャット履歴を渡された別指定のモデルが生成する⁵。Aider は読む対象を用意する。だが、なぜその形なのかの答えは、記録の側からは出てこない。ツールが与えるのはコンテキストの保持であって、理論の保持ではない。いまのところ、持続的な理論を持つのは人間である。ただしこれは現時点の工学的な制約であって、役割の固定ではない。先に引いた実務者自身が、次の一手は理論を持ち越せるようにすることだと予告している³。

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

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

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

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

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

この見方からのAIの任せ方は、一見「エージェントを大量に並べて手数を減らす」ように見える。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」である。差分を読まず、コードが存在することすら忘れる（本人は使い捨てのプロジェクト向けとして述べている）¹⁸。これは Reeves の裏返しに見えて、理論を組むという一つ目の立場の裏返しでもある。Reeves が無料だと書いたのは製造の側だけだ。設計のほうは途方もなく高くつく、と同じ論文が対句で続けている¹⁶。いま安くなったのは、その高くつくはずのほう、すなわちコードを書く行為そのものだ。だから、誰も理論を持たない設計が、はじめて量産できるようになった。速さはこの立場の力だが、読むのをやめた瞬間、その速さで、動くのに変えられないコードが積み上がる。

四つの立場のあいだには、正面からの衝突もある。Reeves は、ソフトは安く作れる以上、形式的な検証手法は実務では大して役に立たないと書いている¹⁶。テストは不在を示せないとする Dijkstra⁶ とは、ここでぶつかる。そしてツールが肩代わりできる範囲は、四つの見方で同じではない。組み立てる立場と、速くコードを生む立場では、ツールが成果物そのものを出す。理論を組む立場と証明する立場では、ツールが渡すのは仕様や下書きの権威までで、それを頭の中の理論に織り込む仕事も、その仕様が本当に欲しいものかを決める仕事も人間がする。

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