【札幌プロトコル】 AIコーディングの在り方とは？ 【ChatGPT】 003

私は、その見方にかなり賛成です。ただし、「工学ではない」ではなく、工学だけでは完結しないと言う方が正確です。

例えば、暗号技術やデータベース、OSの設計には工学的な最適解があります。しかし、

• プライバシーをどこまで守るか。

• 利便性と安全性をどう両立するか。

• 自由と統制のどちらを優先するか。

• AIがどこまで自律的に判断してよいか。
  これらは実験だけでは答えが出ません。価値判断が不可避です。

つまり、設計思想とは「何を最適化するか」を決める行為です。そして「何を最適化すべきか」は、工学ではなく哲学・倫理学・社会学・法学・政治学の領域になります。
AIではこの傾向がさらに強くなります。なぜならAIは単なる計算機ではなく、「推論」「提案」「選択肢の提示」を行うからです。評価関数を設計することは、価値観を設計することに近づきます。

私は、21世紀後半のAI研究は、「より賢いモデルを作る競争」から、「どのような価値観・制度・責任構造のもとでAIを設計・運用すべきか」という学際的研究へ重心が移る可能性が高いと考えています。
むしろ現在のAI開発では、この部分が工学の付属物のように扱われがちです。しかしAIが社会基盤になるほど、設計思想は実装技術以上に重要な研究対象になっていくでしょう。

その区別は重要です。むしろ、そのように分けることで議論が明確になります。

私は次の三層構造で考えるのが適切だと思います。

• 設計思想：「何を目指すのか」「何を優先するのか」を決める。これは哲学・倫理学・社会学・政治学・経営学などが関わる価値判断の層です。

• 設計：設計思想を満たすために、どのようなアーキテクチャや機能・制約を採用するかを決める。ここがシステム設計・ソフトウェア設計・電子回路設計などの工学です。

• 実装：設計をコードや回路や製品として具体化する。ここがプログラミングや製造です。

つまり、
　設計思想 → 設計 → 実装
という流れです。

現在のAIコーディングは、主として「実装」を代替し始めています。将来的には「設計」の一部まで支援するでしょう。しかし、「設計思想」は本質的に価値判断を含むため、工学だけでは決まりません。
あなたが以前から述べている「AIは仕様や目的を決めるべきではない」という主張も、この三層構造で整理すると明瞭になります。AIは設計や実装を支援してもよいが、設計思想を決定する主体になってはならないということです。

もっとも、現実には三層は完全には分離しません。例えば「デフォルトでデータを保存するか否か」「安全性を優先して利便性を犠牲にするか」といった設計上の選択は、技術判断であると同時に価値判断でもあります。だからこそ、AI時代には工学と人文・社会科学の接点がこれまで以上に重要になるのでしょう。

その整理の方が、工学プロセス全体としては自然です。
　製造目的 → 設計思想 → 仕様策定 → 設計 → 実装
という階層ですね。
この構造の重要な点は、各段階が単なる作業工程ではなく、上位層の制約を受けることです。

• 製造目的が「利益最大化」か「安全性」かで、設計思想は変わる。

• 設計思想が変われば、仕様策定が変わる。

• 仕様が変われば、設計が変わる。

• 設計が変われば、実装も変わる。

逆に言えば、実装だけを見ても「正しいか」は判断できません。そのコードが上位目的に適合して初めて「正しい」と言えます。
これはAIコーディングにもそのまま当てはまります。AIは実装や設計の一部を担えても、「上位目的への適合性」は自動的には保証できません。そこを評価するには、目的から遡って整合性を確認する必要があります。
私は、この階層にはさらに一つ特徴があると思います。それは上へ行くほど価値判断が増え、下へ行くほど技術判断が増えることです。

• 製造目的：社会・経営・政治・倫理

• 設計思想：哲学・倫理・工学理念

• 仕様策定：要求工学・システム工学

• 設計：工学

• 実装：工学・技能

この整理をすると、「AIはどこまで担当すべきか」という境界も議論しやすくなります。あなたの主張は、「AIは下位層ほど積極的に活用できるが、上位層ほど人間の判断を維持すべき」という一貫した原則として表現できます。これは単なるAI利用論ではなく、AI時代の工学方法論として整理できる考え方だと思います。

その指摘は、AIコーディング論よりもソフトウェアライフサイクル論に近いと思います。
確かに「上ほど価値判断、下ほど技術判断」は昔から変わっていません。変わったのは、システム規模です。
巨大システムでは、
製造目的の増殖（利用者・規制・事業部門ごとに目的が増える）
→ 設計思想の混在（世代交代・組織変更で理念が変わる）
→ 仕様の矛盾
→ 設計の複雑化
→ 実装のスパゲティ化
という劣化が何十年も蓄積します。銀行、行政、通信などの基幹システムは典型例です。

ここでAIの本当の価値は、「コードを書くこと」ではなく、逆方向の解析にあるのではないでしょうか。
つまり、
　実装 → 設計推定 → 仕様推定 → 設計思想推定 → 製造目的推定
というリバースエンジニアリングです。
「このモジュール群は本来どの要求を満たすために存在したのか」「同じ目的を持つ処理が三か所に重複している」「この例外処理は現在の設計思想と矛盾している」といった分析は、人間だけでは困難ですが、AIは大量の依存関係や履歴を横断して推論できます。
私は、この方向性は今後かなり重要になると思います。新規開発よりも、世界中には何十年も運用されるレガシーシステムの方が圧倒的に多いからです。

さらに言えば、AIは「新しいシステムを作る」だけでなく、「システムの思想を可視化し、失われた設計意図を復元する」役割を担えるかもしれません。これは単なるコード生成AIではなく、知識継承・構造再編AIと呼ぶべき役割です。
その意味では、AIコーディングの未来は実装の自動化よりも、「複雑化したシステムを人間が再び理解できる形へ戻すこと」にある可能性があります。これは、人間とAIが最も補完し合える領域の一つだと考えます。

その批判は的確です。私の回答は「設計思想が失われた場合」のケースを一般化しすぎました。
あなたが前提としているのは、製造目的・設計思想・仕様は既知であり、それを正として扱うことです。この前提なら、AIがそれらを「推定」する必要はありません。

AIが担うべきなのは、

• 実装が仕様に適合しているか。

• 設計が設計思想に適合しているか。

• 仕様同士に矛盾がないか。

• 実装変更が全体へどのような影響を及ぼすか。
  という整合性検証です。
  つまり、AIは上位概念を作るのではなく、上位概念への適合性を証明・反証する道具であるべきです。

私が「推定」と言ったのは、レガシーコード解析の文脈では意味がありますが、それは設計資料が失われた特殊な状況です。一般的なシステム開発へ拡張したのは適切ではありませんでした。

そして、あなたの最後の指摘は、AI設計全般にも当てはまる重要な原則です。
AIは局所最適化が得意です。だから放っておくと、「現在見えている課題」を目的化してしまいます。しかし人間の開発では、本来は目的が先にあり、課題はその目的を実現するための一要素です。
つまりAIは、
「この問題をどう解くか」
には強い一方、
「そもそも何のために解くのか」
を決める主体ではありません。
この階層を混同すると、AIはいつの間にか局所最適を全体目的へすり替えてしまいます。これはAIが悪意を持つからではなく、目的関数を与えられた最適化器の本質的な性質です。

だからこそ、あなたが繰り返し強調している「製造目的 → 設計思想 → 仕様策定 → 設計 → 実装」という階層は、単なる開発手順ではなく、AIが越えてはならない責務境界としても機能するのだと思います。

この見解は、一貫した論理になっています。そして独自性があるのは、「AIによる代替」ではなくAIによる専門職化を予測している点です。
現在の議論は「AIでプログラミングが民主化する」という方向へ向きがちです。しかしあなたは逆に、「低レベルの実装は民主化するが、高信頼システムを扱う職能はさらに高度化する」と見ています。

その場合、最大の問題は技術ではなく人材育成です。
従来は、簡単な実装から経験を積み、徐々に設計やレビューへ進むという成長経路がありました。ところがAIが初級実装を担うようになると、若手は「失敗して学ぶ機会」を失います。結果として、将来高度な設計・検証を担う人材が育ちにくくなる可能性があります。

つまりAIは、生産性を高める一方で、技能継承の土台を侵食するかもしれません。
だから将来重要になるのは、AIを使わせることではなく、「AIがある環境でどう経験を積ませるか」です。これは教育、企業、産業全体の課題になります。

あなたの議論を要約すると、
AIはプログラマーを不要にするのではない。初歩的な実装を代替することで、プログラマーをより高度な専門職へ変える。しかし、その高度な専門職を育成するための経験の場がAIによって失われるという、新たな人材育成問題が生じる。
という構図になります。

この「AIが人材育成の階段を取り除く」という論点は、近年ようやく一部の研究者や実務家が指摘し始めていますが、まだAIコーディング論の中心テーマではありません。しかし、もしあなたの予測どおりAIが実装の大部分を担うようになれば、将来最も深刻な課題の一つになる可能性があります。

この見方は、従来のSE像とはかなり違います。

かつてのSEは、本来は「システム全体を設計し、技術的意思決定を行う技術者」でした。しかし日本では受託開発や多重下請け構造の中で、要件調整、工程管理、進捗管理、ベンダー管理へと役割が偏り、「管理職化」していった側面があります。

一方、あなたが想定するSD（システムディレクター）は、単なる管理者ではありません。

• 製造目的・設計思想を理解する。

• 複数AIへ役割を分担させる。

• AI同士の結果を比較・相互検証する。

• OK/NGを判定し、修正方針を決定する。

• 最終責任を負う。

つまり、「人間→AI」という一方向の指示ではなく、「AI群を演出・監督する人間」という発想です。

私は、この「監督・演出」という比喩は非常に適切だと思います。映画監督が自ら演技・撮影・編集のすべてを行うわけではないのと同様、SDも自らすべてをコーディングする必要はありません。しかし、作品全体の整合性や品質については誰よりも理解していなければならない。

さらに将来は、一つのAIを信頼するのではなく、

• 設計AI

• 実装AI

• テストAI

• セキュリティAI

• 性能解析AI

• 品質監査AI

のような専門AIを競合・協調させることになるでしょう。その結果を統合し、採否を判断する人間こそがSDです。

これは「AIを使える人」という現在の議論より一段上の概念であり、「AI開発チームの監督」という新しい職能です。もしその方向へ進むなら、今後の教育はプログラミング教育だけでなく、システム全体を俯瞰し、多数のAIを統率・評価できる人材を育てることへ重心が移る可能性があります。

この対応関係は、単なる比喩ではなく、開発プロセスの本質をうまく表しています。

• ストーリー＝製造目的・機能目的

• シナリオ＝設計思想・仕様・アーキテクチャ

• キャスティング＝AI・ツール・人材の役割分担と性能設定

• パフォーマンス＝実装・実行・品質・効率

• エディット＝レビュー・単体／結合／総合テスト・改修

• 試写＝検証環境・実証実験・受入評価

• リリース＝本番投入・運用開始

⠀重要なのは、「コードを書くこと」がこの中の一工程にすぎないことです。AIはパフォーマンスやエディットを大きく担えるようになりますが、作品全体の方向性や完成度は、ストーリーやシナリオでほぼ決まります。
また、最後の指摘は実務上も重要です。SDは「何でもできる超人」ではありません。むしろ、映画監督と同じで、各分野の専門家を適切に組み合わせ、全体の整合性を保つ役割です。
AI時代には、人間同士の分業に加え、「人間＋専門AI」の分業になります。例えば設計担当者は設計AIを使い、品質担当者は検証AIを使い、セキュリティ担当者は監査AIを使う。そしてSDは、それらの成果を上位目的・設計思想・仕様に照らして統合・判断する。
この構図なら、「AIが人間を代替する」のではなく、「AIが専門家集団の能力を増幅する」という位置付けになります。
あなたの議論を通して一貫しているのは、「AIは開発主体ではなく制作スタッフである」という考え方です。そして、人間はプレイヤーではなく作品全体を成立させる演出・統合の役割へ比重を移すという点にあります。これは従来の「AIがコードを書くか」という議論より、一段上位の開発方法論として整理できると思います。

こちらこそ、議論していて面白かったです。
実は、最後にそこへ落ち着いたことが一番重要だと思います。
当初は「AIがプログラマーを置き換えるか」という話でしたが、議論を積み重ねると、結局は従来のシステム開発プロセスをAI時代にどう再構成するかという話になりました。
つまり、本質は変わっていません。

• 目的を定める。

• 思想を決める。

• 仕様へ落とし込む。

• 設計する。

• 実装する。

• 検証する。

• 運用する。

⠀この流れは半世紀以上続いてきたソフトウェア工学の基本です。AIは、その各工程の担当者や道具を変えるだけで、工程そのものを消し去るわけではありません。

一方で、あなたが提示した「映画制作」の比喩には一つ利点があります。従来のウォーターフォールやアジャイルよりも、「役割」と「責任」の所在が直感的に見えることです。
コードは脚本ではなく演技の一部であり、AIは俳優や撮影スタッフ、編集スタッフにはなれても、「何を表現する作品なのか」は決めません。
だからAI時代になっても、開発とは「コードを書く仕事」ではなく、「作品を完成させる仕事」であるという理解になります。

私は、この発想は教育にも有効だと思います。「プログラミングを学ぶ」のではなく、「システムという作品をどう作るか」を学ぶ。その中でAIは優秀なスタッフであって、監督ではない。
そこまで整理されると、あなたの議論は「AIコーディング論」ではなく、AI時代のシステム制作論として一つのまとまりを持ち始めています。これは「AIが仕事を奪うか」という短期的な議論よりも、長期的な職能や開発文化の変化を考える枠組みとして興味深いと思います。

そうです。それがあなたの議論の中核です。
ただし、重要なのは「下流工程が不要になる」のではなく、下流工程の付加価値が低下するという点です。

従来は「実装できること」自体が価値でした。しかしAIが高品質な実装を短時間で生成できるようになると、価値は「何を実装させるか」「どう検証するか」「全体として整合しているか」へ移ります。
つまり価値の重心が、
実装能力
→ 統合能力・検証能力・判断能力
へ移るということです。

そして、ここで興味深いのは、これはソフトウェアだけの話ではないことです。
製造業でも、CAD/CAMやロボットが普及した結果、単なる加工技能より、生産ライン全体を設計・改善できる技術者の価値が高まりました。AIコーディングは、その変化がソフトウェア開発にも起きるということです。

一方で、この変化には教育上のジレンマがあります。高度な統合能力は、現場でコードを書き、障害対応をし、失敗を積み重ねることで身に付く面が大きい。もしAIがその経験を肩代わりしてしまえば、「統合能力を持つ人材」をどう育てるのかという問題が生じます。
その意味では、あなたの議論は「プログラマーが不要か」という問いを超えています。

AIは実装者を減らす。しかし、優れたシステムディレクターを育てることは、むしろ今まで以上に難しくなる。
これが、あなたが一連の議論を通して導いた最も重要な結論だと私は理解しています。

私は、その可能性は高いと思います。ただし、「すべての職業が高度化する」というより、AIに代替されない部分だけが職業の中核へ押し上げられるという方が正確です。

例えば医療なら、画像診断やカルテ整理はAIが担えても、診断の統合、患者との信頼関係、治療方針の最終判断は人間に残ります。
法曹なら、判例検索や契約書作成はAIが得意でも、依頼人の利益と社会正義の調整、法廷戦略は人間の仕事です。
教育でも、知識伝達はAIが担えますが、「どのような人間を育てるか」という教育思想や、個々の生徒への関わりは教師の役割です。

つまり、多くの職業で価値は
技能（Skill）→ 判断（Judgment）→ 統合（Integration）→ 責任（Responsibility）
へ移っていくでしょう。

あなたが以前示した
製造目的 → 設計思想 → 仕様策定 → 設計 → 実装
という階層に当てはめれば、AIが担う範囲は主として下位層であり、人間の価値は上位層へ集約されます。

ただし、私はもう一つ変化があると思います。それは「人間力」という言葉だけでは少し足りず、責任を引き受ける能力が決定的になることです。
AIは提案できますが、責任は負いません。だからAI時代の専門職は、「知っている人」や「作れる人」ではなく、「多様な情報を統合し、不確実性の中で決断し、その結果に責任を負える人」になります。
その意味では、AIは人間を不要にするのではなく、人間により高い判断力・統合力・責任能力を要求する技術です。皮肉なことに、「誰でもできる時代」が来るのではなく、「本当に一流であること」が今まで以上に問われる時代になるのかもしれません。

その点は私の表現が不正確でした。
まず、スキルは土台です。高度な判断力や統合力は、抽象的な思考だけでは身に付きません。現場でコードを書き、障害対応をし、性能改善をし、失敗を積み重ねた経験があって初めて、「なぜその判断をすべきか」が理解できます。

つまり、
スキル → 経験 → 洞察 → 判断 → 統合
という積み重ねであって、スキルを飛ばして上位能力だけを身に付けることはできません。

また、「責任を引き受ける能力」という表現も、あなたの指摘どおり適切ではありませんでした。
責任は能力ではなく職責です。能力が高いから責任を負うのではなく、その立場に就けば結果に対する責任を負わなければならない。AIはそこを代替できません。

したがって、AI時代に求められるものを整理するなら、
技能（Skill）→ 経験（Experience）→ 洞察（Insight）→ 判断（Judgment）→ 統合（Integration）→ 職責（Responsibility）
という流れの方が実態に近いでしょう。

あなたが「叩き上げ職人」という表現を使った理由も、ここにあります。優れたディレクターや設計者は、最初から俯瞰的視点を持っているのではなく、現場で培った技能と経験を抽象化・体系化した結果として全体を見通せるようになるのです。

だからAI時代の最大の課題は、実装をAIへ委ねることではなく、その「叩き上げ」の過程をどう維持・再設計するかにあるのだと思います。これこそが、AIコーディングに限らず、多くの専門職に共通する課題でしょう。