― AI PMに必要な「設計思想」とは ―

序章

AIXは「普通のITプロジェクト」と違うのか

近年、多くの企業がAI導入に取り組んでいる。

しかし実際には、PoC止まり、現場定着せず、使われないシステムになるケースが非常に多い。

「精度が低い」「RAGがうまくいかない」「プロンプトが悪い」

そうした技術的な問題のように見えるが、課題が本当にそこにあるケースは少ない。

本当の原因は、プロジェクトの進め方そのものが間違っていることがっぽ

実装から始めることの弱み

AIX（AI Transformation）プロジェクトで最も多い失敗パターンはこれだ。

とりあえず作ってみる

とりあえずDifyで組んでみる

とりあえずプロンプトを書いてみる

一見、アジャイルで良さそうに見える。

しかしこれは「実装先行」であり、設計が存在していない。

AIXは、単にAIを組み込むことではない。

業務構造の再設計プロジェクトである。

業務理解をしないままAIを差し込むと、次のようなことが起こる。

• AIが答えてはいけないことに答える
• エスカレーション設計がない
• 責任の所在が曖昧になる
• 精度問題の原因が分からない
• 改善の方向性が見えない

そして最終的にこうなる。

「やっぱりAIは使えない」

だが本当に使えないのはAIだろうか。それとも設計思想だろうか。

AIXは“AI導入”ではない

従来のIT導入は、明確な仕様がある。

• 入力があり
• 処理ロジックがあり
• 出力が定義される

エラーが出れば止まる。

間違っていればクラッシュする。

だがAIXは違う。

• 曖昧な指示でも動く
• 不完全でも答える
• それっぽい文章を出す
• エラーを出さない

つまり、

「間違っていても動いてしまう」

これが最大の違いだ。

AIXは「正しく作る」ことよりも、

どの構造が正しいのかを探索し続けるプロジェクト

なのである。

AIXは“仕事を疑うプロジェクト”である

AIに仕事を任せると、必ず起こることがある。

それは、

自分たちが何をしていたのか・どう指示すればAIでも働いてもらえるのか、分からなくなる

という現象だ。

例えば問い合わせ対応。

人間は無意識に次のことをしている。

• 送り主の属性を見る
• 緊急性を感じ取る
• 怒っているかどうか察知する
• マニュアルを思い出す
• 判断に迷ったら上司に確認する

だがそれを言語化できていない。

AIにやらせて初めて気づく。

あれ、こんなに考えてたっけ？

AIXとは、AIを作ることではない。

自分たちの仕事の構造を可視化すること

である。

だからAIXは難しい

AIXは技術プロジェクトに見えるが、本質は違う。

• 業務理解・設計思想・判断基準の明確化・役割分担の再定義・責任の所在の設計

これらを扱う。

つまり、

組織の成熟度が問われるプロジェクト

なのである。

この前提を押さえないまま、

プロンプトやRAGや実装技術の話に入ると、必ず迷子になる。

第1章：AIXプロジェクトの基本構造

5層設計モデルで理解する

AIXが失敗する最大の理由は、「設計の抽象度」が混ざってしまうことにある。

• 業務分析と設計が混ざる
• 役割分担と実装が混ざる
• 問題設定とプロンプトが混ざる

結果として、

どこを直せばいいのか分からない

という状態になる。

これを防ぐために必要なのが、AIXの構造を層で捉えることである。

AIXは少なくとも5層でできている

AIXプロジェクトは、次の5層で構成される。

第1層：目的（実現したいオペレーション）

最上位にあるのは「何を作るか」ではない。

どんな状態を実現したいのか？

例えば：

• 問い合わせ一次対応をAIが担い、人は例外処理に集中する
• レジ10台を1人で回せるオペレーションを作る
• 社内問い合わせの80%を即時回答できる体制にする

これは機能ではなく、オペレーション像である。

ここが曖昧なまま進むと、すべてがぶれる。

第2層：人とAIの役割分担（コンセプト設計）

次に来るのが、

何をAIに任せ、何を人が担うのか

という思想。ここがAIXの本丸である。

重要なのは、

• 「緊急なら人間」ではない
• 「怒っているなら人間」でもない

状況によって変わる。

だから必要なのは

ポリシーの定義

である。

例えば：

• 一次回答はAIが必ず出す
• 最終確定は人間が承認する
• 金銭に関わる最終判断は人間のみ

このレベルはまだアルゴリズムではない。

あくまで設計思想である。

第3層：ワークフロー設計

次に、

具体的にどう流れるのか？

を設計する。

例：

1. 問い合わせ受信
2. 内容分類
3. ナレッジ参照
4. 緊急度判定
5. 回答 or エスカレーション

ここではじめて「流れ」が出てくる。

しかしまだ処理単位は曖昧でよい。

重要なのは、

判断がどこで行われるか

を明確にすること。

第4層：アルゴリズム/パイプライン設計

ここから具体性が増す。

• 緊急度はどう判定するのか？
• ナレッジは1件か複数か？
• 回答が曖昧ならどうするか？

ここでは、

グラデーション判断

が出てくる。

通常ITは「Yes / No」である。

AIXは違う。

• 高い
• やや高い
• 不明
• 低い

という曖昧な評価を持つ。

この曖昧性を含めて設計するのがAIXの特徴である。

第5層：処理単位の仕様

最後に、

• プロンプト
• JSON構造
• 入出力形式
• ノード構成

といった具体的な仕様に落ちる。

ここが実装に最も近い。

だがここから始めると、必ず破綻する。

なぜ5層の設計が重要なのか？

AIXが失敗するとき、多くは第5層から始める。

• とりあえずプロンプトを書く
• とりあえずRAGを組む
• とりあえずノードをつなぐ

それが問題ではないが、成果を大きく/着実に出すために、

実践を通じながら5層とも明らかにしていくことが必要になる。

しかし上位層が未定義のままでは、

• 何を評価すべきか分からない
• 精度が悪い理由が分からない
• 改善方向が見えない

つまり、

問題の位置が特定できない

抽象度を行き来できるPMが必要

AIXプロジェクトでは、

• 目的を見直す
• 役割分担を再設計する
• フローを修正する
• アルゴリズムを変える
• プロンプトを直す

これらを何度も往復する。

どの層に問題があるのかを判断できるPMがいなければ、プロジェクトは迷走する。

設計と実装の境界が曖昧になる理由

従来ITでは、

• 設計はドキュメント
• 実装はコード

という明確な分離があった。

AIXでは、

• ノード設計自体がほぼ設計
• JSON構造定義が仕様
• プロンプトがアルゴリズム

つまり、

設計と実装の距離が極端に短い

だからこそ抽象度を意識しないと、常に迷子になる。

まとめ

ここまでで分かるのは、

AIXは「技術プロジェクト」ではなく

「設計抽象度を行き来するプロジェクト」

であるということだ。

しかし、もう一つ重要な点がある。

この5層は、上から順番に終わるものではない。

第2章：AIXは循環型プロジェクトである

AIXプロジェクトを「ステップ」で設計し進行したくなる気持ちは分かる。

1. 業務分析
2. 設計
3. 実装
4. 評価
5. 改善

一見すると分かりやすい。

しかし、この理解のまま進めると失敗しやすい。

なぜならAIXは、上から順番に終わるプロジェクトではないからだ。

AIXは“常に1に戻る”

通常のITプロジェクトでは、

• 要件定義が終われば次へ
• 設計が固まれば次へ
• 実装が完了すればテストへ

という進み方を比較的しやすい。

もちろん多少の手戻りはあるが、基本は前進型で進行が行える。

しかしAIXでは、次のような現象が起きる。

• 出力を見て初めて業務観点の抜け漏れに気づく
• 実装して初めて役割分担の甘さが分かる
• 評価して初めて評価軸がズレていると分かる

つまり、

実装や評価が、業務理解を更新してしまう

のである。これは本質的な違い。

なぜ戻るのか？

AIXでは、AI（機械）に仕事をさせることで初めて人間の無意識が可視化される。

中途採用しかしていなかった会社が新卒を雇い始める時と似ている。

例えば問い合わせ業務。

人間は無意識にこうしている。

• 送り主の属性を見る
• 緊急度を感じ取る
• 過去履歴を思い出す
• 文脈から意図を推測する
• 自分の裁量範囲を確認する

しかしこれらは、マニュアルに書かれていないことが多い。

AIに任せると破綻する。その会社特有の判断ロジックはそこら中に溢れている。

そして初めて気づく。

あれ、こんなことも判断していたのか？

この瞬間、プロジェクトは第1層（業務理解）に戻る。

「評価」が最も重要な工程になる理由

従来ITではテストは最終工程に近い。

AIXでは評価が目的設計・アルゴリズム設計・プロンプト設計の全ての中心工程になる。

なぜなら、

• 機械的に仕事を1つの正解を定義することができない。
• 最終出力だけをみても精度が出ない原因が分からない
• 精度は多層的な設計のどこを変えるべきかの判断が難しい

例えば回答が不適切だった場合、

• ナレッジが悪いのか
• チャンクの単位や検索（渡している内部情報の切り取り方）が悪いのか
• 処理内容を決める分類ロジックが甘いのか
• プロンプト（指示）が曖昧なのか
• 役割分担思想（何をAIにさせるべきか）が間違っているのか

原因は層をまたぐ。

だから評価は1つ1つの出力への要素診断であると同時に、

「AIXプロジェクトの5層設計の構造診断」でなければならない。

ウォーターフォールに見せることの危険性

AIXを「5ステップ」で教えると、PMやジュニアはこう誤解する。

• 分析が終われば次に進める
• 設計が固まれば実装できる
• 実装すれば運用開始できる

しかし実際は、

設計と実装は往復する

実装と分析も往復する

もしウォーターフォール的に進めてしまうと、

• 上位層の誤りが放置される
• 改善が局所最適になる
• 何を直せばいいのか分からなくなる

そしてこうなる。

「精度が上がらない」

しかし精度の問題ではない。構造の問題だ。

循環型プロジェクトの本質

AIXはこう考えるべきである。

1. 仮の構造を作る
2. 出力を観察する
3. 業務理解を更新する
4. 構造を修正する
5. 再度動かす

これを回し続ける。

重要なのは、

どの層を直しているのかを意識すること

である。

• 目的がズレているのか
• 役割分担が甘いのか
• フローが不適切なのか
• アルゴリズムが粗いのか
• 処理仕様が弱いのか

これが分からなければ、改善は迷走する。

AIXに必要なのは「戻れる設計」

AIXで重要なのは、

修正可能性を残すこと

である。

• Pythonで固めすぎない
• 条件分岐を固定しすぎない
• 仕様を硬直化させない

なぜなら構造は必ず変わるからだ。

最初の設計が正解であることは、ほぼない。

まとめ

ここまでで分かるのは、

AIXは

直線型ではなく、循環型の設計プロジェクト

であるということだ。

しかし、もう一つ重大な誤解がある。

それは、

AIを「完成品」として扱ってしまうこと

である。

次章では、なぜAIは「後輩」として扱うべきなのかを解説する。

第3章：AIは採用ガチャのない後輩である

AIXプロジェクトが壊れる瞬間は、技術的な限界ではない。

それは、ある“態度”が生まれた瞬間である。

「こんなことも分からないのか？」

この一言が出たとき、プロジェクトは静かに崩壊を始める。

AIは優秀な後輩である

AIは膨大な知識を持っている。

• 一般知識は豊富
• 言語理解能力も高い
• 論理的整理もできる

だが決定的に欠けているものがある。

あなたの会社の仕事を知らない

という事実だ。

これは新入社員と同じである。

• 会社の暗黙ルールを知らない
• 「それは常識」という前提を知らない
• 例外処理の勘所を知らない
• どこまでが裁量なのか分からない

それでも仕事はする。

それっぽい答えを出す。

ここがAIXの怖さである。

「考えればわかること」しか分からない

AIの出力がズレるとき、多くの場合こう考えてしまう。

• モデルが悪い
• 精度が低い
• プロンプトが弱い

しかし本質は違う。

そもそも教えていない

可能性が高い。

人間の後輩に対しても同じだ。

• 判断基準を伝えていない
• エスカレーション条件を教えていない
• 例外パターンを説明していない
• 重要度の優先順位を共有していない

それなのに、なぜできない？と怒るのはおかしい。

あなたはあなたの認識以上にその会社や周囲のことを学習して働いています。

AIの出力はAIX設計の「鏡」である

AIの出力は、

自分たちの業務理解の写像

である。

例えば問い合わせ対応。

AIがこう答えたとする。

「その件についてはマニュアルをご確認ください」

それを見て、

• 冷たい
• 不親切
• 実務に合わない

と思ったとする。

だがそこで問うべきは、

• どういうときにマニュアル参照だけでよいのか？
• どの程度の説明を補足すべきか？
• トーンはどの程度柔らかくするのか？

これらが設計されていない可能性である。

AIは育成型プロジェクトでなる

AIXの特徴は、

作るのではなく、育てる

に近いことだ。

• 判断基準を明示する
• NGパターンを定義する
• グラデーション評価を設計する
• エスカレーションルールを整える

これらを追加することで、AIは徐々に“仕事を覚える”。

このプロセスを許容できない組織では、AIXは続かない。

「AIを完成品と見るか、成長体と見るか」

ここが最大の分岐である。

AIを完成品として扱うと：

• 一発で完璧を求める
• 失敗を許容しない
• 仕様を固定する
• 改善の余地を閉じる

AIを成長体として扱うと：

• 評価が中心になる
• 中間判断を見る
• 設計を更新する
• 層を戻ることを許容する

AIXは後者でしか成立しない。

まとめ

ここまでで見えてきたのは、

AIXは単なる技術プロジェクトではなく、

組織の仕事観を試すプロジェクト

であるということだ。

しかし、まだ大きな違いがある。

それは、

従来のIT開発とは、設計思想そのものが違う

という点である。

次章では、IT開発とAIXの決定的な違いを整理する。

第4章：IT開発との決定的な違い

なぜ従来PMスキルが通用しないのか

AIXを難しくしている本当の理由は、

それがITプロジェクトに“見えてしまう”こと

である。

UIがある。ノードがある。APIがある。JSONがある。

だからつい、

いつもの開発と同じだろう

と考えてしまう。

しかし本質はまったく違う。

1. エラーが出ないという恐怖

従来ITでは、

• 書き間違えればエラーが出る
• 仕様違反すれば止まる
• 型が違えば落ちる

つまり、

間違えれば壊れる

これが安全装置になっていた。

しかしAIXでは違う。

• 曖昧でも動く
• 間違っていても返す
• それっぽい文章を出す
• クラッシュしない

つまり、

間違っていても動いてしまう

これが最大の違いであり、最大の危険である。

2. 要件定義が後から分かる

IT開発では、

• 要件を固める
• 仕様を書く
• それを実装する

が基本である。

AIXでは、

出力を見ないと要件が定義できない

という逆転現象が起きる。

AIに仕事をさせてみて、

• あ、ここ判断してたんだ
• あ、このケース抜けてた
• あ、例外こんなにあったんだ

と分かる。

つまり、

要件定義は固定物ではなく、探索物

になる。

これは従来のPM感覚とは大きく異なる。

3. 設計と実装の距離が極端に短い

ITでは、

• 設計書を書く
• エンジニアが実装する

という分業がある。

AIXでは、

• ノード設計
• プロンプト記述
• JSON定義

これらがすぐ動く。

つまり、設計 ≒ 実装に近い。

このため、抽象度を整理していないと、

• 今どの層を触っているのか分からない
• アルゴリズム変更なのか仕様変更なのか曖昧になる

そして迷子になる。

4. 曖昧性を内包した設計が必要

従来ITは基本的にYes/Noの世界だ。

• 0か1か
• trueかfalseか
• 正しいか間違いか

しかしAIXは違う。

• やや高い
• おそらく
• 可能性がある
• 十分ではない

こうした

グラデーション判断

を設計に組み込まなければならない。

これはロジックというより、

思考モデリング

に近い。

5. アルゴリズムが人間の思考に近い

ITは「処理手順」を書く。AIXは「判断構造」を書く。

例えば問い合わせ対応なら、

• 内容分類
• 緊急度評価
• ナレッジ十分性判定
• ポリシー参照
• 総合判断

これらを並列で評価し、総合的に結論を出す。

これは

人間の思考を構造化する行為

である。

6. だからPMの役割が変わる

従来PMは、

• スコープ管理
• 工程管理
• 品質管理
• リスク管理

が中心だった。

AIXでは加えて、

• 業務の本質理解
• 判断基準の言語化
• 役割分担の再設計
• 評価構造の設計

が求められる。

つまり、業務設計者に近づく。

7. 精度問題の正体

AIXでよく聞く言葉がある。

精度が低い

だが精度は結果である。

原因は多層にある。

• 問題設定がズレている
• 役割分担が曖昧
• ワークフローが粗い
• アルゴリズムが単純すぎる
• ナレッジ単位が壊れている
• プロンプトが曖昧

IT的発想では、

実装を直せば精度が上がる

と思ってしまう。

しかしAIXでは、上位層を直さなければ改善しないことが多い。

AIXは「技術力」ではなく「構造理解力」

ここまで整理すると明らかである。

AIXの難しさは、

• モデルの性能
• RAGの設定
• ノードのつなぎ方

ではない。

抽象度を行き来しながら構造を整理できるかどうか

である。

従来のIT成功体験があるほど、

• 固めたくなる
• 早く実装したくなる
• ロジックで閉じたくなる

しかしAIXではそれが罠になる。

第5章：典型的な失敗パターン

AIXプロジェクトは、派手に失敗することは少ない。

むしろ、

• なんとなく動いている
• なんとなく微妙
• なんとなく改善しない
• なんとなく使われなくなる

という形で静かに終わる。

ここでは、実際によく起きる

典型的な失敗パターンを整理する。

失敗① 実装先行症候群

最も多いのがこれである。

とりあえず作ってみる

• ノードを組む
• RAGを入れる
• JSONを定義する
• Pythonを書き始める

しかし、

• 問題設定が曖昧
• 役割分担が未定義
• フロー設計が粗い

状態で実装すると、必ずこうなる。

• 精度が安定しない
• 何を直せばいいか分からない
• 改善が場当たりになる

典型的には、

条件分岐を増やしていく

ことで対処しようとする。

そして次の失敗に入る。

失敗② 直列if地獄

本来、判断は並列で行われている。

• 緊急度
• 内容分類
• ナレッジ十分性
• ポリシー適合性

これらは同時に評価されるべきだ。

しかし実装先行すると、

if 緊急:
    人間対応
elif ナレッジ不足:
    エスカレーション
elif 不適切利用:
    警告
else:
    AI回答

のような直列分岐になる。

すると何が起きるか。

• 本当は回答できるのに止まる
• グラデーションが消える
• 判断が極端になる
• 人間の思考から乖離する

これはAIX特有の設計破綻である。

失敗③ RAGチャンク崩壊問題

RAGを入れた瞬間、多くの人が「高度化した」と感じる。

しかし最も壊れやすいのがここだ。

典型的な問題：

• チャンク単位が壊れている
• 見出しだけがヒットする
• 情報が欠損する
• 無関係な3件を必ず返す

結果として、

参照しているように見えて参照していない

状態になる。

ここで多くの人は

• モデルが悪い
• ベクトルが悪い

と考える。

だが本質は、

知識の単位設計

である。

失敗④ 問題設定不在

これは構造的に危険な失敗だ。

• 分析する
• 役割分担を考える
• フローを書く
• 実装する

しかし、

何を良くしようとしているのか

が明確でない。

その結果、

• 精度が上がっているのか分からない
• 改善の方向性が曖昧
• スコープが膨張する

これは「目的層」が未定義である状態だ。

失敗⑤ グラデーション設計欠落

AIXでは、

• 完全にOK
• やや危険
• 不明
• 明確にNG

といった段階が存在する。

しかし多くの場合、

OKかNGか

の二択に落としてしまう。

すると、

• 本来補助できたケースを捨てる
• 人間介入が過剰になる
• AIが活かされない

AIXの本質は、

グラデーションをどう扱うか

にある。

失敗の共通性。静かに壊れる。

これらの失敗には共通点がある。

抽象度が混ざっている

• 上位層の問題を下位層で直そうとする
• 設計問題をプロンプトで解決しようとする
• 目的の曖昧さを条件分岐で補おうとする

これが迷走の正体である。

AIXは「壊れ方が静か」。AIXはクラッシュしない。

だから失敗に気づきにくい。

• なんとなく動く
• なんとなく微妙
• なんとなく改善しない

そして、使われなくなる。これが最も危険な終わり方だ。

第6章：AIXは「誰が何をするか」を再定義するプロジェクト

この章の結論はシンプル。

AIXとは、AIを導入することではない。

「組織内の仕事の分担を再設計すること」である。

成功するAIXは、

• 技術的に高度なプロジェクトではない
• 役割分担が上手なプロジェクトである

Amazon Goとセルフレジ

AIXを考える上で、非常に分かりやすい比喩がある。

それが、**Amazon Go・セルフレジ、**である。

どちらも「自動化」の文脈で語られるが、結果は大きく異なる。

この違いは、AIXの本質を示している。

完全自動化の幻想

Amazon Goは、理想的な自動化の象徴だった。

• レジに並ばない
• 会計不要
• 商品を持って出るだけ

まさに完全自動化。

だが実際には、

• 実証実験で止まった
• 店舗展開は限定的
• 運用コストが高い

セルフレジはなぜ成功したのか？

一方でセルフレジは、

• 全国に普及
• ほぼすべてのスーパーに導入
• 当たり前のオペレーションになった

なぜ成功したのか。

それは、

人と機械の最適分担を設計したから

である。

セルフレジは完全自動ではない。

• 基本操作は利用者
• 支払いも利用者
• トラブル時はスタッフ
• イレギュラー対応は人間

つまり、

機械がやるべきことと

人がやるべきことを切り分けた

のである。

AIXは「Amazon Go」になろうとすると失敗する

AIXでよくある失敗は、

できるだけAIにやらせようとする

ことだ。

• すべて自動回答
• 完全自律エージェント
• 人間介入なし

しかし現実は違う。

• 判断には文脈がある
• 責任が発生する
• 組織ポリシーがある
• 感情が絡む

ここを無視すると破綻する。

重要なのは「どこで人が入るか」

AIXで考えるべきは、「AIに何をやらせるか」ではなく、 「人はどこで介入するか」である。

なぜなら、責任は最終的に人間が持つからだ。

設計すべきなのは、

• 人が確認するタイミング
• 人が承認するポイント
• 人が例外判断する箇所

である。

役割分担は固定ではない

重要なのは、役割分担は一度決めて終わりではないということだ。

• 最初は人間多め
• 徐々にAI範囲拡大
• 評価を通じて調整

これは漸進的自動化に近い。

Amazon Go型は一気に全自動を目指す。

セルフレジ型は段階的に最適化する。

AIXは後者でなければならない。

なぜ役割分担が最上位設計なのか

役割分担が曖昧なまま進めると、

• フローが不安定
• アルゴリズムがブレる
• 実装が複雑化する
• 精度が安定しない

逆に役割分担が明確なら、

• フローが整理され
• 判断基準が明確になり
• 改善方向が見える

役割分担は、設計の起点である。

第7章：AIXを成功させるPMとは何者か

AI時代に求められるプロジェクトリーダー像

ここまで整理してきた通り、AIXは単なるAI導入プロジェクトではない。

• 業務構造を可視化し
• 役割分担を再設計し
• 判断基準を言語化し
• 評価を回し続ける

極めて構造的で、しかも循環型のプロジェクトである。

では、このプロジェクトを成功させられるPMとは、

どのような人物なのか。

AIXにおけるPM定義

従来のPMは、

• スコープを守る人
• 工程を守る人
• 品質を守る人

だった。

AIXのPMは、

• 構造を見抜く人
• 抽象度を管理する人
• 評価を設計する人

以下は具体的な性質論をまとめてみる。

1. 仕事を疑い続けられる人

AIXで最も重要な資質は、

仕事を疑えること

である。

• 本当にこの手順は必要か？
• なぜここで確認しているのか？
• その判断基準は明示されているか？
• それは暗黙知ではないか？

AIは、仕事の曖昧さをあぶり出す装置である。

だからPMは、業務を正当化する人ではなく、業務を構造化する人でなければならない。

2. 抽象度を行き来できる人

AIXでは、

• 目的
• 役割分担
• フロー
• アルゴリズム
• 仕様
• 実装

を常に往復する。

例えば、

• 精度が悪い → アルゴリズムの問題か？
• いや役割分担が曖昧か？
• そもそも目的が過剰か？
• ナレッジ単位が壊れていないか？

これを見抜ける人が必要だ。

抽象度を固定してしまうPMは、AIXでは迷走する。

3. 評価を中心に据えられる人

AIXは評価設計のプロジェクトである。

最終出力だけを見るPMは危険。

必要なのは、

• 中間判断を可視化する
• 判定根拠を見られるようにする
• グラデーション評価を扱う
• 改善の方向を構造的に特定する

評価を回せるPMだけが、AIXを持続させられる。

4. 処理を完成品としてみない人

AIを完成品と見るPMは、

一度の失敗でプロジェクトを止める。

AIを後輩と見るPMは、

• 教えていないことを疑う
• 判断基準を追加する
• 役割を調整する
• 改善を前提に設計する

この違いは大きい。

AIXは、教育型プロジェクトに近い。

5. 技術に逃げない人

AIXが停滞すると、多くの人が技術に逃げる。

• モデルを変えよう
• ベクトルDBを変えよう
• Pythonを書こう
• より高度なエージェントにしよう

しかし本質は多くの場合、

• 目的層の曖昧さ
• 役割分担の未整理
• 判断基準の不明瞭さ

にある。

技術は解決策ではない。構造理解こそが解決策である。

6. 完璧を目指さない人

AIXは最初から完成しない。

• 70%でも運用開始できる設計にする
• 人間介入前提で回す
• 改善ループを回す

これを許容できるPMでなければならない。

Amazon Go型を目指すのではなく、

セルフレジ型で段階的に進める

発想が必要だ。

7. 組織の成熟度を理解している人

AIXは、組織の鏡である。

• 判断基準が曖昧な組織
• 責任範囲が曖昧な組織
• 業務が属人化している組織

では、AIは必ず揺れる。

PMは技術だけでなく、

組織の成熟度

を見なければならない。

AIXは、組織変革プロジェクトでもある。

終章：AIXは技術プロジェクトではない

ここまで、AIXプロジェクトの構造を整理してきた。

• 実装から入ると失敗する
• 5層構造で考える必要がある
• ウォーターフォールではなく循環型である
• AIは後輩として扱うべきである
• IT開発とは設計思想が違う
• 役割分担が成功を決める
• PMの抽象度管理力が鍵になる

これらを一言でまとめるなら、こうなる。

AIXは技術プロジェクトではない。

AIを作るのではない

多くの組織が誤解している。

• モデルを導入すれば変革できる
• RAGを入れれば高度化する
• エージェントにすれば自律する

だが、AIは魔法ではない。

AIは、構造がなければ揺れる。

だからAIXでやっていることは、

AIを作ること

ではなく、

仕事の構造を明示化すること

である。

AIは仕事の“鏡”である

AIに業務を任せると、

• 判断基準の曖昧さ
• 例外処理の多さ
• 暗黙知の多さ
• 属人化の深さ

が浮き彫りになる。

つまりAIXは、

組織の成熟度テスト

でもある。

構造化されていない組織ほど、AIは不安定になる。

逆に言えば、AIXを通じて組織は成熟する可能性もある。

最重要

この前提が揃ってれば設計作業もAIでさぼりまくりましょう。

• 仕事を疑い
• 判断を言語化し
• 役割を再定義し
• 改善を回し続ける

地味で、構造的な営みでありますが、努力しろと言いたい気持ちはないです。

この文章でも何でもいいのでプロンプトをaiに作らせるのではなくどんな分担にすべきか、どんな全体設計で、どう評価すべきかについてAIに相談しまくりましょう。

作業をサボることと成果に無責任なことは全く別だと考えてます。

とにかく実装を作って動くようにして、育成プロセスや出力への解釈も他者に委ねるようなAIX PMは無責任だな。と感じています。