はじめに：あるベテラン技術者のコメント

先日、投稿した記事にこんなコメントをもらった。

「商用サービスの開発現場で品質担保の厳しさを経験した者から見れば、AI生成コードをプロダクトに組み込むリスクは明らかだ。AIの真のメリットはバグ修正やリファクタリングの効率化にある。1,000〜7,000行規模のコード生成を繰り返せば、アイソレーション設計の必要性がわかる。設計情報はYAML等で定義すべきで、自然言語の曖昧な指示に頼るべきではない。業務レベルの品質には、開発者がコードの内部構造を完全に把握していることが絶対条件だ。」

開発だけを考えれば、このコメントは正しい。

だが、ここに日本の開発者から抜け落ちている視点がある。

私が「全体を見る」ことを学んだ現場

私のソフトウェア開発のキャリアは、30年前に県職員として県の財務会計システム開発のチームリーダーを務めたところから始まった。

この経験が、今の視点の原点になっている。

行政システムの開発では、コードを書くことは仕事ではない。予算要求の根拠を財政課に説明し、業務フローを現場の職員からヒアリングし、運用マニュアルを作成し、研修を実施し、規則を改正し、導入後のサポート体制を構築する。

設計、実装、テスト、ドキュメント、運用、ユーザー教育──すべてが自分の責任範囲だった。

「コード」は仕事ではない。でも、使いやすいシステムを作らなければ動かないし、セキュリティも考慮しないといけない。だから、全体を見渡さなければ、何も完成しない。それを最初に叩き込まれた。

だからこそ、冒頭のコメントを読んで感じる。視野が狭い、と。

「開発の現場」しか見ていない

このコメントの視野は「開発工程」に閉じている。

コードの品質。テストの網羅性。リファクタリングの効率。すべて開発者の視点だ。

だが問いたい。

QAがどれだけ苦労してテストケースを設計しているか、知っているか。テクニカルライターがどれだけ苦心してマニュアルを書いているか、見たことがあるか。サポート担当がどれだけユーザーからの問い合わせに追われているか、想像したことがあるか。

「品質担保の厳しさを知っている」と言いながら、見えているのは自分の工程だけではないか。

AIの真価は「一気通貫」にある

AIをコード生成ツールとしてだけ見ていると、その本質を見誤る。

設計・実装・テスト・ドキュメント・保守を一気通貫で完了させる。 これがAIの真の価値だ。

コーディング、テスト、保守まで考慮して設計する。その設計をAIに伝える。すると、実装コード、テストコード、ユーザーマニュアルが、整合性を保ったまま一気に生成される。

工程間の情報伝達ロスがゼロになる。仕様書とコードの乖離が原理的に発生しない。従来の「品質担保」作業の多くが、そもそも不要になる。

この恩恵を受けられるのは、全ての現場を見渡せる設計者だけだ。

自然言語という最強のインターフェース

「設計情報はYAML等で定義すべき、自然言語に頼るべきではない」というコメントがあった。

逆だ。

「AIには自然言語で指示できる」─ これは革命的な変化だ。

重要なのは、形式化された仕様書を書くことではない。自然言語で意図を伝え、生成された成果物を確認できること。それだけでいい。

形式知への変換はAIの仕事だ。人間の仕事は、その成果物が正しいかどうかを判断することにある。

つまり、設計は日本語でできる。

開発のプロである必要はない。YAMLの文法を知らなくてもいい。必要なのは、全体を考慮して設計し、生成された成果物を確認する能力だ。

確認能力としての設計力

ここで逆説が生まれる。

形式化のスキルが不要になった分、設計能力は従来以上に重要となった。

ただし、ここで言う「設計能力」は、コードを書く力ではない。

「こう設計すればテストしやすい」「こう実装すればドキュメント化しやすい」「こう構造化すれば保守しやすい」─ これらを同時に考慮し、AIが生成した成果物を見て「これでいいか」を判断する力だ。

コードの内部構造を完全に把握する必要はない。全体の整合性を判断できればいい。

日本の開発現場が抱える構造的問題

なぜこの視点が抜け落ちているのか。

日本の開発現場が縦割りだからだ。

設計者が設計書を書き、実装者がコードを書き、QAがテストし、テクニカルライターがマニュアルを書く。自分の担当領域で評価され、昇進し、「現場を知るベテラン」として尊重される。

その結果、全体を見渡せる人材が育たない構造ができてしまった。

私が県職員時代に経験したような「全工程を一人で見る」機会は、今の日本の開発現場ではむしろ稀だ。大企業のSIer文化が支配的で、工程ごとに別会社が担当することすらある。

もちろん、全工程を一人で完璧にこなせという話ではない。
問題は、全工程を理解している人間が、設計の主導権を持っているかどうかだ。

ここで言う「全工程」には、当然、開発も含まれる。
それは決して簡単ではない。だが、AIの助けを借りれば十分に可能な範囲になった。

実装の細部をすべて手で書ける必要はない。
重要なのは、設計・実装・テスト・ドキュメント・運用がどう連動するかを理解し、
生成された成果物を見て「これは成立しているか」を判断できることだ。

分業そのものが問題なのではない。
分業を統合する視点を、誰が持つのか ─ そこが問われている。

そして、その前提条件となる作業の多くは、今後、AIが担うようになっていく。
だからこそ、人間に求められる役割は「工程を分けること」ではなく、
分けられた工程を一つのシステムとして成立させる判断を下すことへと移っていく。

AIは格差を拡大する技術でもある。

これがAI導入の本当の難しさ

「全ての現場を知る」という覚悟。

正直に言えば、これは簡単にできることではない。長年一つの領域で専門性を磨いてきた技術者に、「その経験だけでは足りない」と言っているのだ。

だが、これこそがAI導入の本当の難しさなのだ。

ツールの使い方を覚えることではない。プロンプトの書き方を習得することでもない。自分の専門領域を超えて、全ての工程を見渡す視野を獲得すること。それが最大のハードルだ。

組織の縦割りを維持したままAIを導入しても、各工程が少し効率化するだけで終わる。一気通貫の恩恵は得られない。

技術的な問題ではない。組織の問題であり、個人のマインドセットの問題だ。

おわりに：問われているのは視野の広さ

冒頭のコメントは、開発者として正しい。アイソレーション設計の重要性も、学び続ける姿勢の必要性も、その通りだ。

だが、その視点は狭すぎる。

AI時代に生産性を爆発的に高められるのは、開発のプロではない。全体を見渡して設計できる人だ。

私は県の財務会計システム開発で、その視点を最初に学んだ。予算、業務、運用、教育 ─ コードの外側にある全てを見なければ、システムは完成しないことを知った。

「AIをどう使うか」の前に、「全ての現場を見渡す視野をどう獲得するか」を考えるべきだ。

AIの導入で問われているのは、スキルではない。現状の専門領域の外まで、責任を持って考える覚悟があるかどうかだ。

私はClaude web版やClaude codeを使って、自然言語で設計意図を伝え、コード、テスト、ドキュメントの整合性を対話しながら開発している。

開発のプロでなくても、全体を見渡せる人間であれば、Claudeと組むことで一気通貫の開発が可能になる。
もしあなたが「開発は専門外だが、システム全体の責任を負う立場」にいるなら、Claudeに相談してみてほしい。
そこから見える景色が変わるはずだ。

AIの能力がどれだけ急激に上がっているかについては、ダボス会議2026でのClaudeとGeminiの生みの親の対談をまとめた記事を参照してください。