思考の空洞化を防ぐ技術品質再建計画

業務品質標準マニュアル：AI活用成果物の実機稼働検品基準

1. 総論：AI時代のエンジニアリング品質とオーナーシップ

インフラ設計の現場において、生成AIが作成する「もっともらしい成果物」が蔓延している。しかし、AIが生成するのは学習データに基づいた確率的な「文字列」に過ぎない。我々エンジニアが顧客に提供すべきは、実機での稼働を保証し、泥をかぶる覚悟を含めた「責任の所在」である。

無批判なAI利用は「認知の外注（Cognitive Offloading）」を招き、エンジニアの脳を中空化させる。例外処理が8割を占めるインフラの世界で、一般論しか吐けないAIに思考を委ねることは、SIerとしての死を意味する。設計段階の1のミスが、実装・運用フェーズでは30倍から100倍のコストとなって跳ね返り、深夜3時のサーバールームで静まり返るシステムを前に立ち尽くすことになる。今、我々に求められているのは、AIを「副操縦士」として従えるための圧倒的な「地肩」の強さである。

エンジニアの「地肩（判断力と文書センス）」の定義

検証的論理思考： AIの回答を「正解」ではなく「仮説」と捉え、MS Learn等の一次ソースから因果関係を逆演算し、技術的必然性を証明できる能力。

多角的文脈把握： クラウドの一般論を、顧客固有の「15年来のレガシーなAD属性」や「プロキシのセッション上限」といった泥臭い制約と結合し、矛盾のない設計へ翻訳する能力。

メタ認知とオーナーシップ： 「自分は何を知っており、何を確認すべきか」の境界を峻別し、アウトプットに対して「自分の判子」を押せるプロとしての責任感。

AIという強力すぎる武器を暴発させないため、まずは組織的枠組みとして「能力に応じたAI利用の制限と許可」を定義する。

--------------------------------------------------------------------------------

2. AI活用免許制度（Menkyo）：習熟度別の権限定義

本制度は単なる制限ではなく、エンジニアとしての「責任能力の証明」である。インフラ設計は「機長（人間）」が責任を負うべき空路であり、副操縦士（AI）に操縦桿を丸投げすることは許されない。特に若手には、論理回路を脳内に構築するための「AI断食」を課す。

ランク名	判定基準（実機検証能力・エビデンス提示力等）	許可されるAI利用範囲
白帯（ブロンズ）	AIなしでMS Learnのみを参照し、自力で検証環境を構築・設定できる。「AIを触る前に10分間自力で検索する」癖がついている。	原則禁止。思考のプロセスを自機で回し、エンジニアとしてのOSを構築する修行期間。
初段（シルバー）	AI生成物のハルシネーション（嘘）を自力で発見し、一次ソースを提示して修正できる。構成案の批判的検品が可能。	補助的利用のみ。構成案の壁打ちやアイデア出しに限定。ただし、設計値の根拠はすべて自力調査を義務付ける。
皆伝（ゴールド）	障害発生時にAIのせいにせず、自力で原因究明と復旧ができる者。Idempotency（べき等性）Graph API、Hybrid Identity等の複雑な変数を統合できる。	無制限（フル活用）。ただし、成果物には必ず実機検証ログと一次ソースの紐付けを義務付ける。

免許ランクに関わらず、すべての設計書には以下の「3つの検品レンズ」による評価が適用される。

--------------------------------------------------------------------------------

3. 三層構造（3レイヤー）による検品フレームワーク

レビューアーは、AIの「抽象的な一般論」を即座に撃ち落とすため、以下のレンズを用いて「レビュアーの連撃（Reviewer's Strike）」を繰り出す。

自社特有のレンズ（文脈の確認）

AIはM365の仕様は知っているが、眼前の顧客の「15年前から残っているレガシーなAD属性」や「独自のセキュリティポリシー」は知らない。

「これはGoogle検索で出る内容だ。この顧客固有のAD属性やプロキシ制約を考慮した記述はどこにある？」

「弊社の過去の類似案件での失敗事例（移行時の認証競合等）が反映されているか？」

「既存のオンプレ資産との競合リスクを、実機ログに基づいて説明できるか？」

相手（顧客）の顔のレンズ（観点の確認）

AIは「一般的な読者」を想定するが、設計書は「特定の運用担当者」が迷わずに動くための指示書である。

「この手順で、現場のXXさんは迷わず作業できるか？運用負荷を無視した理想論になっていないか？」

「顧客が最も懸念している『最悪のシナリオ（全社ログイン不能等）』に対する回答が含まれているか？」

「技術用語の羅列になっていないか？相手のITリテラシーに合わせた『翻訳』がなされているか？」

解像度（具体性）のレンズ（実効性の確認）

「適切に」「柔軟に」という言葉は、AIの逃げ口上であり、エンジニアの責任放棄である。

「すべての形容詞を、具体的数値（ms、%、TPS、JUAS非機能要件グレード等）に置き換えたか？」

「正常系だけでなく、異常系や境界値（256文字のパス長制限等）が定義されているか？」

「明日から実行するとして、最初の一歩（どのポータルのどのボタンを押すか）がイメージできるか？」

--------------------------------------------------------------------------------

4. インフラ設計特化型：AI生成物の「地雷」検知リスト

M365導入においてAIが最も間違いやすく、かつ見落としがちな項目を「地雷」と定義する。これらはデスマーチの引き金となる項目である。

AIが書きがちな抽象表現	現場で必要な具体的記述	修正が必要な理由（So What?）
「セキュリティを考慮し、MFAを有効化する」	「条件付きアクセスを用い、社内IP以外はMFA必須とする。ただし、PSTN/Hybrid Identity環境下のレガシー認証複合機は除外設定とする」	AIは古い複合機の「認証方式の衝突」を無視し、導入初日に全拠点のスキャン機能を止めるため。
「効率的なツールでデータを移行する」	「SharePointの256文字パス制限をチェックし、Throttling（制限）を回避するため夜間帯に分散移行する」	AIはAPIの物理的な制限やスロットリングを知らず、移行スケジュールを根底から破綻させるため。
「ライセンスはE3以上を推奨する」	「Teams Phone機能が必要なため、アドオン費用を含めたコスト比較を行う。またはE5へのアップグレードを検討する」	AIはライセンス体系の頻繁な変更を追いきれず、数千万円単位の試算ミスを招くため。

検品原則： すべての記述にMicrosoft Learnの一次ソースURLを併記せよ。URLなき記述は「未検証の仮説」として却下する。

--------------------------------------------------------------------------------

5. 心理的バイアスの排除：自称経験者への「物理的」対処法

能力の低い者ほど自分の能力を過大評価する「ダニング＝クルーガー効果」に陥った自称経験者には、論理的な誘導は通用しない。彼らには論理ではなく、「物理（実機での失敗）」を突きつける「クラッシュ・テスト」による現実校正が必要である。

言い訳（AIもそう言っている等）	レビューアーの切り返し（事実による制圧）
「AIもこの設定がベストだと言っている。経験上これで動く」	「AIは弊社と保守契約を結んでいない。今ここで、その設定値で動くことを検証テナントで見せてくれ。10分待つ」
「これは解釈の問題だ。細かい数値にこだわる必要はない」	「インフラに解釈の余地はない。実機でエラーが出るなら、それは欠陥品だ。JUAS基準に照らした数値を今すぐ出せ」
「後で直せばいい。まずは終わらせることが先だ」	「設計の穴は後工程で30倍から100倍のコストになる。君の『手抜き』のために仲間をデスマーチに追い込むことは許さない」

--------------------------------------------------------------------------------

6. 結言：次世代エースを育てるための「健全なブレーキ」

本マニュアルはAIを排除するためのものではない。AIを「魔法の杖」と勘違いしている者を、実機で語れる「本物のエンジニア」へと叩き直すためのブートキャンプである。特に、現在AIを使わずに自力で苦労している若手こそ、将来AIを完璧に乗りこなす「機長（Captain）」になれる最強のエース候補である。彼らの「地肩」を鍛える時間を、組織として全力で守り抜く。

品質担保のための品質管理責任者・マネージャー行動規範

「AI生成率」ではなく「人間による修正・追記率」を評価の軸に据え、独自の価値が乗っていない成果物は即座に却下せよ。

一次ソース（公式ドキュメント）と実機検証ログの添付がない設計書は、レビューの土俵に上げるな。

「タスクを終わらせること」を目的とする思考停止を断固として拒絶し、「動くものを作ること」へのオーナーシップを徹底的に追求せよ。