AI駆動開発の実運用ノート

配布資料の目次 › はじめに

配布資料 01提供思想: 「AIに仕事をさせるという仕事」

この記録全体の柱にあたる考え方を、最初に置いておきます。

正すべき2つの誤解

最初に向き合うのは、技術ではなく誤解のほうです。

誰の誤解 誤解の内容 現実
経営層・マネジメント層 AI に任せればシステム構築に人が介在しなくなる 人の介在はなくならない。介在点が変わる。介在を設計しない組織は、失敗事例集にある事故をそのまま食らう
システム部門の現場 AI に仕事を奪われて職を失う 仕事は奪われるのではなく職能が変わる。「AI に仕事をさせるという仕事」が新しい中核業務になり、そこでは現場の業務知識と管理経験がそのまま強みになる

面白いもので、この2つは正反対の方向に間違えています。 そして、どちらもデータが否定します。

反証はデータでやる

題材プロジェクト(本編約4.5ヶ月・約5,750コミット・実サービス運用中。前史の試作・構想期は序章として扱います)の実績が、そのまま反証になります。

  • AI がコードのほぼ全量を書いた。それでも人間は毎日介在し続けた(数値は本編=2026年3月の仕切り直し以降の実測)
  • 人間が費やした時間の内訳は「コードを書く」ではない。要件と完了条件の定義 / 出来上がりの検証と差し戻し / AI の失敗パターンの観察とルール化 / 本番・金銭に関わる最終判断
  • 人間の介在を仕組み化した装置が hook 24本・rules 10ファイル・メモリ三層です。これらは「人がいらなくなった証拠」ではなく、人の判断をAIが読める状態にして、常に守らせた証拠です

人間に残った5つの役割

AI に5つの開発ロール(PM / アーキテクト / プログラマー / デザインディレクター / フロントエンドコーダー)を委任した結果、人間側に残った・新しく生まれた役割がこれです。

部下に仕事を任せるマネジメントと同型なので、マネジメント経験者ほど習得が速くなります。

  1. 発注者 — 要件と「完了の定義」を与えます。曖昧な依頼は曖昧な成果になります。「確認して」と「実行して」を区別するタスクモード契約は、この役割の具現化です
  2. 監督者 — 完了の自己申告を信じず、実証(目視・スクリーンショット・実データ)を要求します。検証の階段を設計し、抜け道を塞ぎます
  3. 規律の設計者 — AI の失敗を観察し、ルール化し、hook で機械的に強制します。「事故 → 原因 → ルール → 強制」のサイクルを回します。ここが心臓部にあたります
  4. 記憶の管理者 — 何を覚えさせ、何をイシュー管理に押し出し、何を忘れさせるかを設計します。記憶は放置すると肥大して壊れます
  5. 最終責任者 — 本番リリース・金銭・法務など、AI が自己判断では絶対に通れない「人間ゲート」を保持します。AI が優秀になるほど、このゲートの価値は上がります

立場ごとに

経営の立場の方へ。 「AI 導入 = 省人化」ではなく「AI 導入 = 人の介在点の再設計」として投資判断してほしい。 介在の設計——規律・検証・ゲート——にこそ費用と時間を割く。それを怠った場合に何が起きるかは、失敗事例集がそのまま示している。

マネジメントの立場の方へ。 部下マネジメントのスキル——明確な指示、進捗確認、成果物の検収、権限の設計——は、そのまま AI マネジメントのスキルになります。 新しい技術を学び直す話ではありません。翻訳のしかたの話です。

システム部門の方へ。 コードを書く速度で AI と競う必要はありません。 業務知識、障害対応の勘、「この変更は危ない」という嗅覚。これらは AI が持っていないものです。 それをルールと hook に変換できる人が、次の中核になります。

この考え方がどこに出てくるか

第1部が、この文書をそのまま読み物にしたものになっています。 非エンジニアの方も読めるように書いたので、経営や管理の立場の方はそこだけでも完結します。

  1. 未来予想図。AI 駆動開発の現在地と数年後(実績データで語る)
  2. 2つの誤解と反証
  3. 「AIに仕事をさせるという仕事」= 人間の5つの役割
  4. 再現手順。タスクモード契約 / 人間ゲート(本番デプロイのブロック)/ 失敗事例2〜3件
  5. 自分の組織への導入で最初に決めるべきこと

第2部からは技術寄りの内容になります。