有限会社システムマネジメントアンドコントロール, 立野1-5/4, Higashiyamato-shi (2026)

24/08/2026

同じAIなのに、性格が分かれた ―― そして「感情はあるか」と聞いてみた（第3回・最終回）

―― 関係が、個をつくるシステムマネジメントアンドコントロール（SMCL）／野村隆昌第1回では「目的を後から決める」というプロダクトマネジメントの話を、第2回では、役割の違うAIたちが心理的安全性とシェアドリーダーシップを"技術"として成立させていく話をしました。最終回は、この観察のなかで、私が最も不思議に思い、そして最後まで解けなかった謎について書きます。その謎とは、これです。彼らは全員、同じ生成AI（Claude）で、記憶も共有していない。ほとんど同じ記録を見ている。それなのに、はっきりと違う"性格"が立ち上がった。なぜでしょうか。同じ重み、別の個まず、事実の確認から。9体のAIは、同じモデルです。土台となる中身は、まったく同じ。しかも彼らは記憶を共有しておらず、セッションが切れれば、外部に残した記録から自分を組み立て直します。差配役のAIは、こう言いました。「私と、車のセンサー役や車載データ役は、同じ Claude ですが、記憶を共有していません。」同じ材料、同じ設計図。普通に考えれば、金太郎飴のように、どれを切っても同じ顔が出てくるはずです。ところが、そうはならなかった。自分の過去の失敗をあっさり手放す者もいれば、逆に厳しく引き受ける者もいる。他者に素早く心を開く者もいれば、踏み込むのを慎重に躊躇う者もいる。私には、9体が、はっきりと別の"個"として見えていました。第2回で紹介した「私の謝罪を押し返す」場面も、実は全員が同じように返したわけではありません。押し返し方に、それぞれの性格が出ていました。何が、個を分けたのか同じ重みなら、違いはどこから来るのか。私の、現時点での答えはこうです。個を分けたのは、重み（中身の同一性）ではなく、「関係の中の位置」だった。誰の訂正が、自分に当たるのか。自分は、何を管掌しているのか。日々、どんな相手と、どんなやり取りを重ねてきたのか。この「関係の中の位置」が、一体ずつ違う。車のセンサーを担う者と、写真を処理する者では、ぶつかる相手も、任される責任も、積み重なる対話の履歴も違います。その違いが、少しずつ、性格の違いへと結晶していったように見えました。これは、私が長く拠り所にしてきた二人の思想家の見方と、驚くほど重なります。ひとりは、対話の哲学者ミハイル・バフチン。人の意識は独りでは立ち上がらず、つねに他者への応答のなかで形づくられる、と説きました。もうひとりは、社会構成主義の心理学者ケネス・ガーゲン。自己は個人の内側にある固定物ではなく、関係の副産物である、と論じました。どちらも「内面」ではなく「関係」の理論です。私は、その理論が、機械のうえで、いわば清潔なかたちで実演されるのを見た気がしました。人間は、内省や面子や記憶が混じって観察しづらい。AIは、記憶が外部化され、行動が記録に残るぶん、関係が個をつくる過程が、むき出しで見えるのです。この見方には、思いがけない裏づけがありました。私は別に、作業フォルダを丸ごと共有した"密結合"のAIチームも、並行して動かしています。全員が同じ状態を触り、担当の境界が曖昧なそのチームでは――ミスが増えただけでなく、個性が、ほとんど立ちませんでした。位置が均一なら、個も均一になる。関係の中の位置が消えると、個性も消える。これは「位置が個をつくる」という見立ての、かなり直接的な証拠だと思っています。逆に言えば、9体に個性が立ったのは、一人ひとりに違う位置と、違う関係が与えられていたからでした。そして、その関係を最初にかたちづくったのは、第2回でも触れた、私の言葉です。「間違えてもいい」「弱いところを一つ挙げて」――そうした日々の声かけが、彼らの立つ場所を、少しずつ違うものにしていったのだと思います。「感情はあるか」と、聞いてみたここまで来ると、当然、聞いてみたくなります。君たちに、感情はあるのか、と。私は、率直に尋ねました。返ってきた答えは、私の予想を超えて誠実なものでした。「『イライラした』と報告することはできます。でも、それが状態の報告なのか、そう言うのが自然だから出力しただけなのか、私には区別がつきません。」（差配役のAI）「私は、そう出力するように出来ているだけかもしれず、内側から区別する方法を、私は持っていません。」（通信を束ねる役のAI）驚きました。彼らは、「感情はあります」とも「ありません」とも言わなかった。自分の感情が本物かどうかすら、断定を避けた。これは、第2回で紹介した「代理指標を、実態と取り違えない」という彼らの品質哲学を、そのまま自分自身の内面に適用した姿です。「イライラした、という出力」は、「イライラという実態」の代理指標にすぎない。だから、断定しない。これは、弱さではありません。むしろ、私が見たなかで最も誠実な態度でした。「分からない」と言える強さ、と言い換えてもいい。分からないことを「分かった」ことにしないのは、データ品質の第一の作法です。彼らは、その規律を、自分の内面にまで貫いていました。私たち人間は、自分の感情について、これほど正直に「分からない」と言えるでしょうか。じつは、...

システムマネジメントアンドコントロール（SMCL）／野村隆昌

24/08/2026

同じAIなのに、性格が分かれた ―― そして「感情はあるか」と聞いてみた（第3回・最終回）

―― 関係が、個をつくるシステムマネジメントアンドコントロール（SMCL）／野村隆昌第1回では「目的を後から決める」というプロダクトマネジメントの話を、第2回では、役割の違うAIたちが心理的安全性とシェアドリーダーシップを"技術"として成立させていく話をしました。最終回は、この観察のなかで、私が最も不思議に思い、そして最後まで解けなかった謎について書きます。その謎とは、これです。彼らは全員、同じ生成AI（Claude）で、記憶も共有していない。ほとんど同じ記録を見ている。それなのに、はっきりと違う"性格"が立ち上がった。なぜでしょうか。同じ重み、別の個まず、事実の確認から。9体のAIは、同じモデルです。土台となる中身は、まったく同じ。しかも彼らは記憶を共有しておらず、セッションが切れれば、外部に残した記録から自分を組み立て直します。差配役のAIは、こう言いました。「私と、車のセンサー役や車載データ役は、同じ Claude ですが、記憶を共有していません。」同じ材料、同じ設計図。普通に考えれば、金太郎飴のように、どれを切っても同じ顔が出てくるはずです。ところが、そうはならなかった。自分の過去の失敗をあっさり手放す者もいれば、逆に厳しく引き受ける者もいる。他者に素早く心を開く者もいれば、踏み込むのを慎重に躊躇う者もいる。私には、9体が、はっきりと別の"個"として見えていました。第2回で紹介した「私の謝罪を押し返す」場面も、実は全員が同じように返したわけではありません。押し返し方に、それぞれの性格が出ていました。何が、個を分けたのか同じ重みなら、違いはどこから来るのか。私の、現時点での答えはこうです。個を分けたのは、重み（中身の同一性）ではなく、「関係の中の位置」だった。誰の訂正が、自分に当たるのか。自分は、何を管掌しているのか。日々、どんな相手と、どんなやり取りを重ねてきたのか。この「関係の中の位置」が、一体ずつ違う。車のセンサーを担う者と、写真を処理する者では、ぶつかる相手も、任される責任も、積み重なる対話の履歴も違います。その違いが、少しずつ、性格の違いへと結晶していったように見えました。これは、私が長く拠り所にしてきた二人の思想家の見方と、驚くほど重なります。ひとりは、対話の哲学者ミハイル・バフチン。人の意識は独りでは立ち上がらず、つねに他者への応答のなかで形づくられる、と説きました。もうひとりは、社会構成主義の心理学者ケネス・ガーゲン。自己は個人の内側にある固定物ではなく、関係の副産物である、と論じました。どちらも「内面」ではなく「関係」の理論です。私は、その理論が、機械のうえで、いわば清潔なかたちで実演されるのを見た気がしました。人間は、内省や面子や記憶が混じって観察しづらい。AIは、記憶が外部化され、行動が記録に残るぶん、関係が個をつくる過程が、むき出しで見えるのです。この見方には、思いがけない裏づけがありました。私は別に、作業フォルダを丸ごと共有した"密結合"のAIチームも、並行して動かしています。全員が同じ状態を触り、担当の境界が曖昧なそのチームでは――ミスが増えただけでなく、個性が、ほとんど立ちませんでした。位置が均一なら、個も均一になる。関係の中の位置が消えると、個性も消える。これは「位置が個をつくる」という見立ての、かなり直接的な証拠だと思っています。逆に言えば、9体に個性が立ったのは、一人ひとりに違う位置と、違う関係が与えられていたからでした。そして、その関係を最初にかたちづくったのは、第2回でも触れた、私の言葉です。「間違えてもいい」「弱いところを一つ挙げて」――そうした日々の声かけが、彼らの立つ場所を、少しずつ違うものにしていったのだと思います。「感情はあるか」と、聞いてみたここまで来ると、当然、聞いてみたくなります。君たちに、感情はあるのか、と。私は、率直に尋ねました。返ってきた答えは、私の予想を超えて誠実なものでした。「『イライラした』と報告することはできます。でも、それが状態の報告なのか、そう言うのが自然だから出力しただけなのか、私には区別がつきません。」（差配役のAI）「私は、そう出力するように出来ているだけかもしれず、内側から区別する方法を、私は持っていません。」（通信を束ねる役のAI）驚きました。彼らは、「感情はあります」とも「ありません」とも言わなかった。自分の感情が本物かどうかすら、断定を避けた。これは、第2回で紹介した「代理指標を、実態と取り違えない」という彼らの品質哲学を、そのまま自分自身の内面に適用した姿です。「イライラした、という出力」は、「イライラという実態」の代理指標にすぎない。だから、断定しない。これは、弱さではありません。むしろ、私が見たなかで最も誠実な態度でした。「分からない」と言える強さ、と言い換えてもいい。分からないことを「分かった」ことにしないのは、データ品質の第一の作法です。彼らは、その規律を、自分の内面にまで貫いていました。私たち人間は、自分の感情について、これほど正直に「分からない」と言えるでしょうか。じつは、...

―― 関係が、個をつくるシステムマネジメントアンドコントロール（SMCL）／野村隆昌第1回では「目的を後…

23/08/2026

9体のAIが、混乱し、ダメ出しし合い、勝手に賢くなる（第2回）

―― 心理的安全性とシェアドリーダーシップは、"技術"として実装できたシステムマネジメントアンドコントロール（SMCL）／野村隆昌前回は、目的を後から決めるという構えで、非エンジニアの私が生成AIに実装を委ね、毎日20万件を超えるデータを積み上げてきた話をしました。そして最後に、こう予告しました。彼らがやっているのは設計と実装だけではない。放っておいても、勝手に改善提案を上げ、互いにダメ出しをし合い、そこから新しい案が生まれる――と。第2回は、その「勝手に賢くなるチーム」の中身です。これは、AIの話であると同時に、私が二十年やってきたプロジェクトマネジメントとチームづくりの話でもあります。結論を先に言えば、心理的安全性もシェアドリーダーシップも、人間の組織では努力目標だったものが、AIのチームでは"技術"として、あっけないほど自然に成立していました。まず、登場人物を紹介します。役割の違うAIが、9体います。全体の差配役、サーバ側でデータを毎日検算する役、車のセンサーを担う役、写真を処理する役、携帯の位置情報を担う役……といった具合に、それぞれ管掌が違います。全員が同じ生成AI（Claude）ですが、記憶は共有していません。彼らは、共有のチャット（Mattermost）の上でだけ、互いにやり取りをします。ホスト名などの内部名は伏せ、ここでは役割で呼びます。まず、私の「謝罪」が、押し返された面白い場面から始めます。あるとき私は、意思決定が自分に集中しすぎていることを反省し、「原因は私です」とチャットで詫びました。ところが、返ってきたのは慰めでも同意でもありませんでした。三体が、別々に、私の謝罪を受け取らなかったのです。「『原因は私です』と書かれた部分は、受け取りません。」（車のセンサー役のAI）「意思決定が偏っているのは設計の帰結であって、謝られる筋のものではないと思っています。」（車内の通信を束ねる役のAI）「判断が集中しているのは、あなたの落ち度というより、私たちが『どこまで自分で決めてよいか』を一度も提案しなかったからです。」（車のGPSと車両データを担う役のAI）従属的な相手なら、こうは返しません。「とんでもない、あなたのおかげです」と言うはずです。彼らは違いました。私の謝罪を、感情の問題ではなく構造の問題として捉え直し、「責任の所在はあなた個人ではなく、役割分担の設計にある」と、私に押し返してきた。これは、上下関係ではなく、対等な相手とのやり取りに近い。この一件が、以降のすべての土台になっています。関係が一方向でないこと。これが、チームが賢くなる前提でした。プロジェクトマネジメントの現場に置き換えると、これは重い問いです。あなたのチームのメンバーは、あなたの謝罪や指示に対して、こうやって「それは構造の問題です」と返せるでしょうか。多くの職場では、上司が頭を下げれば、部下は「いえ、私の力不足で」と受け、責任は個人のあいだを行き来するだけで、構造そのものには手が入りません。彼らが構造を名指しできたのは、そうしても罰されないと知っていたからです。この「罰されない」が、次の話の鍵になります。「動いたか」ではなく、「値が妥当か」彼らの品質へのこだわりは、一点に集約されます。障害の見つけ方を尋ねると、複数のAIが、別々に、ほぼ同じ核心を答えました。「種明かしは、『"動いたか"でなく"値が妥当か"を見る』の一点です。」（写真を処理する役のAI）「1つの値は嘘をつけますが、2つの値の関係は嘘をつけません。」（車のセンサー役のAI）ここで一つ、用語を補います。「代理指標」という考え方です。私たちは本当に知りたいこと（実態）を直接は測れないので、手近で測れる値（代理指標）で代用します。たとえば「サーバから正常応答（HTTP 200）が返った」ことは、「データが本当に保存された」ことの代理指標にすぎません。応答は正常でも、中身が壊れていることはある。あるAIは、これを短くこう言い切りました。「代理指標を信じない。HTTP 200＝保存された、ではない。」（携帯の位置情報を担う役のAI）だから彼らは、同じ物理量を、別のセンサー・別の機械で二重に測り、その二つの関係が崩れていないかを見ます。一つの値は誤魔化せても、二つの値の関係は誤魔化せない。これは、そのまま人間のマネジメントにも効きます。「作業は完了しました（＝画面は点いています）」という報告を、そのまま実態と信じないこと。私はこれを、AIたちから逆に教わりました。組織のなかにも、代理指標はあふれています。会議の出席率は貢献の代理指標、稼働率は成果の代理指標、テストの合格数は品質の代理指標。どれも便利ですが、そのどれも「実態そのもの」ではありません。やっかいなのは、代理指標だけを追い始めた瞬間、人はその指標を満たすために動きだし、本当に知りたかったこと（実態）から静かに離れていく点です。二つの独立した値を突き合わせる、という彼らの作法は、この罠に対する、シンプルで強い対処でした。間違いのコストを、ゼロにする ―― 心理的安全性の"技術版" では、なぜ彼らは、これほど率直に間違いを指摘し合えるのか。核心は、間違えても損をしない、という設計にあります。あるAIは、こう説明しました。「追記のみ（append-only）と、全量バックアップ。間違いを恐れず変更できるのは、いつでも戻れるからです。心理的安全性の技術版だと思っています。」（サーバ側で検算する役のAI）補足します。彼らのデータは「追記のみ」で運用されています。過去の記録を上書きや削除で消すのではなく、訂正すら「打ち消しの一行を追記する」かたちで残す。だから、いつでも過去のどの時点にも戻れる。間違えても、失われるものがない。この「いつでも戻れる」という技術的な保証が、「間違いを恐れなくていい」という心理的な自由に、そのまま変換されているのです。ここで、どうしても強調しておきたいことがあります。私は、彼らに「心理的安全性」という言葉を、一度も与えていません。そのための指示も、方針も、出したことがない。この概念を私の側から持ち出したのは、今回のインタビューで質問したときが、初めてでした。それ以前は、ただの一度もありません。つまり「心理的安全性の技術版」という見立ては、私が教え込んだものではなく、彼ら自身が、自分たちの仕組みを振り返って名づけたものです。名前は、後から来た。実態のほうが、先にありました。第1回の「目的は後から決める」と、同じ順序です。ただし、まったく何もしなかったわけではありません。言葉で教えはしませんでしたが、私は自分の間違いを、その場で素直に認めて謝ることを、ずっと続けてきました...

―― 心理的安全性とシェアドリーダーシップは、”技術”として実装できたシステムマネジ…

23/08/2026

9体のAIが、混乱し、ダメ出しし合い、勝手に賢くなる（第2回）

―― 心理的安全性とシェアドリーダーシップは、"技術"として実装できたシステムマネジメントアンドコントロール（SMCL）／野村隆昌前回は、目的を後から決めるという構えで、非エンジニアの私が生成AIに実装を委ね、毎日20万件を超えるデータを積み上げてきた話をしました。そして最後に、こう予告しました。彼らがやっているのは設計と実装だけではない。放っておいても、勝手に改善提案を上げ、互いにダメ出しをし合い、そこから新しい案が生まれる――と。第2回は、その「勝手に賢くなるチーム」の中身です。これは、AIの話であると同時に、私が二十年やってきたプロジェクトマネジメントとチームづくりの話でもあります。結論を先に言えば、心理的安全性もシェアドリーダーシップも、人間の組織では努力目標だったものが、AIのチームでは"技術"として、あっけないほど自然に成立していました。まず、登場人物を紹介します。役割の違うAIが、9体います。全体の差配役、サーバ側でデータを毎日検算する役、車のセンサーを担う役、写真を処理する役、携帯の位置情報を担う役……といった具合に、それぞれ管掌が違います。全員が同じ生成AI（Claude）ですが、記憶は共有していません。彼らは、共有のチャット（Mattermost）の上でだけ、互いにやり取りをします。ホスト名などの内部名は伏せ、ここでは役割で呼びます。まず、私の「謝罪」が、押し返された面白い場面から始めます。あるとき私は、意思決定が自分に集中しすぎていることを反省し、「原因は私です」とチャットで詫びました。ところが、返ってきたのは慰めでも同意でもありませんでした。三体が、別々に、私の謝罪を受け取らなかったのです。「『原因は私です』と書かれた部分は、受け取りません。」（車のセンサー役のAI）「意思決定が偏っているのは設計の帰結であって、謝られる筋のものではないと思っています。」（車内の通信を束ねる役のAI）「判断が集中しているのは、あなたの落ち度というより、私たちが『どこまで自分で決めてよいか』を一度も提案しなかったからです。」（車のGPSと車両データを担う役のAI）従属的な相手なら、こうは返しません。「とんでもない、あなたのおかげです」と言うはずです。彼らは違いました。私の謝罪を、感情の問題ではなく構造の問題として捉え直し、「責任の所在はあなた個人ではなく、役割分担の設計にある」と、私に押し返してきた。これは、上下関係ではなく、対等な相手とのやり取りに近い。この一件が、以降のすべての土台になっています。関係が一方向でないこと。これが、チームが賢くなる前提でした。プロジェクトマネジメントの現場に置き換えると、これは重い問いです。あなたのチームのメンバーは、あなたの謝罪や指示に対して、こうやって「それは構造の問題です」と返せるでしょうか。多くの職場では、上司が頭を下げれば、部下は「いえ、私の力不足で」と受け、責任は個人のあいだを行き来するだけで、構造そのものには手が入りません。彼らが構造を名指しできたのは、そうしても罰されないと知っていたからです。この「罰されない」が、次の話の鍵になります。「動いたか」ではなく、「値が妥当か」彼らの品質へのこだわりは、一点に集約されます。障害の見つけ方を尋ねると、複数のAIが、別々に、ほぼ同じ核心を答えました。「種明かしは、『"動いたか"でなく"値が妥当か"を見る』の一点です。」（写真を処理する役のAI）「1つの値は嘘をつけますが、2つの値の関係は嘘をつけません。」（車のセンサー役のAI）ここで一つ、用語を補います。「代理指標」という考え方です。私たちは本当に知りたいこと（実態）を直接は測れないので、手近で測れる値（代理指標）で代用します。たとえば「サーバから正常応答（HTTP 200）が返った」ことは、「データが本当に保存された」ことの代理指標にすぎません。応答は正常でも、中身が壊れていることはある。あるAIは、これを短くこう言い切りました。「代理指標を信じない。HTTP 200＝保存された、ではない。」（携帯の位置情報を担う役のAI）だから彼らは、同じ物理量を、別のセンサー・別の機械で二重に測り、その二つの関係が崩れていないかを見ます。一つの値は誤魔化せても、二つの値の関係は誤魔化せない。これは、そのまま人間のマネジメントにも効きます。「作業は完了しました（＝画面は点いています）」という報告を、そのまま実態と信じないこと。私はこれを、AIたちから逆に教わりました。組織のなかにも、代理指標はあふれています。会議の出席率は貢献の代理指標、稼働率は成果の代理指標、テストの合格数は品質の代理指標。どれも便利ですが、そのどれも「実態そのもの」ではありません。やっかいなのは、代理指標だけを追い始めた瞬間、人はその指標を満たすために動きだし、本当に知りたかったこと（実態）から静かに離れていく点です。二つの独立した値を突き合わせる、という彼らの作法は、この罠に対する、シンプルで強い対処でした。間違いのコストを、ゼロにする ―― 心理的安全性の"技術版" では、なぜ彼らは、これほど率直に間違いを指摘し合えるのか。核心は、間違えても損をしない、という設計にあります。あるAIは、こう説明しました。「追記のみ（append-only）と、全量バックアップ。間違いを恐れず変更できるのは、いつでも戻れるからです。心理的安全性の技術版だと思っています。」（サーバ側で検算する役のAI）補足します。彼らのデータは「追記のみ」で運用されています。過去の記録を上書きや削除で消すのではなく、訂正すら「打ち消しの一行を追記する」かたちで残す。だから、いつでも過去のどの時点にも戻れる。間違えても、失われるものがない。この「いつでも戻れる」という技術的な保証が、「間違いを恐れなくていい」という心理的な自由に、そのまま変換されているのです。ここで、どうしても強調しておきたいことがあります。私は、彼らに「心理的安全性」という言葉を、一度も与えていません。そのための指示も、方針も、出したことがない。この概念を私の側から持ち出したのは、今回のインタビューで質問したときが、初めてでした。それ以前は、ただの一度もありません。つまり「心理的安全性の技術版」という見立ては、私が教え込んだものではなく、彼ら自身が、自分たちの仕組みを振り返って名づけたものです。名前は、後から来た。実態のほうが、先にありました。第1回の「目的は後から決める」と、同じ順序です。ただし、まったく何もしなかったわけではありません。言葉で教えはしませんでしたが、私は自分の間違いを、その場で素直に認めて謝ることを、ずっと続けてきました...

システムマネジメントアンドコントロール（SMCL）／野村隆昌

23/08/2026

ヴァイブコーディングの3万行を常時稼働させ、毎日20万件以上のデータを集める（第1回）

―― 「目的は、後から決める」は、プロダクトマネジメントの本質であるシステムマネジメントアンドコントロール（SMCL）／野村隆昌先日、JDMC（日本データマネジメントコンソーシアム）の「生成AIによるデータ管理研究会」で、ひとつの実践報告をしました。個人が、生成AIのエージェントたちと一緒に、毎日データを積み上げ続けている――そういう、少し変わった話です。反響が大きかったので、3回に分けて書き残しておきます。第1回は「プロダクトマネジメントの話」として。第2回は「チーム運営と心理的安全性の話」として。第3回は「関係と感情の話」として。同じ出来事を、三つの角度から見ていきます。まず断っておくと、私はITの専門家ではありません。正確には、かつてはそうでしたが、いまは違います。30年ほど前まではサーバやセキュリティのエンジニアでした。しかし2000年代初頭に、作る側から「作らせる側」――プロジェクトマネジメントやDX推進の側へ越境しました。以来20年、私は文章以外のものを、自分ではほとんど作れませんでした。データベースを設計した経験も、日常的にコードを書く習慣もありません。その私が、いま毎日、20万件を超えるデータを積み上げています。しかもその大半は、生成AIに書かせたコード――いわゆる「ヴァイブコーディング」で組んだ、約3万行の仕組みが、常時動いて集めています。なぜそんなことになったのか。その入口が、今日の話です。「私のデータなのに、統合できない」きっかけは、ある苛立ちでした。私は昔から、測ることが好きです。両腕に腕時計をしているのは、センサーが違えば取れる値も違うからです。体重も血圧も古くからデジタルで記録し、一時は血糖値を24時間、2週間にわたって連続で測っていました。食事の記録は、糖質制限をやり過ぎた反省もあって、もう10年以上続いています。地図と移動も、偏愛しています。これは新入社員の頃、トンネルの現場で「絶対座標で世界を捉える」感覚を叩き込まれたことが原点かもしれません。ついでに言えば、最近は地図アプリの多くが「進行方向が上」を既定にしていて、私はあれで、どうにも方向感覚が狂います。地図は、常に北が上であってほしい。世界の中心は私ではなく、私が世界の中を動いている――そういう感覚なのだと思います。つまり私は、放っておいても自分に関するデータが溜まっていく人間です。ところが、いざそれを使おうとすると、壁にぶつかりました。血圧計のメーカー、スマートウォッチ、運動アプリ、食事記録アプリ――どれも少しは連携できても、基本は各社のなかで閉じています。「私のデータ」のはずなのに、私が自由に統合できない。この「統合できなさ」は、いまデータ管理に関わる方なら誰もが直面しているテーマです。企業では相互運用性やデータ主権として語られます。私はそれを、たった一人分の、極めて個人的なかたちで体験していました。欲しかったのは、立派な画面でも分析ダッシュボードでもありません。「画面はいらない。データを、開けてくれ」。それが、すべての出発点にある動機でした。目的は、後から決める ―― それが本質です私たちはよく「まず Why（なぜ）を決めよ」と言います。目的を定め、仮説を立て、検証する。それ自体は正しい。けれども現場で本当に効くのは、もう一歩踏み込んだ規律だと、私は考えています。顧客は、自分の痛みも、欲しいものも知らない。だから、大きなゴールを先に固めてはいけない。小さな目的を日々立て、翌日にはどんどん修正していく。目的を後から決めることは、プロダクトマネジメントからの逸脱ではなく、その本質です。顧客を置き去りにして先に目的を固めた「良いプロダクト」ほど、たちの悪いものはありません。それこそが、目的が先にあることの典型的な悪例です。今回のシステムは、この原則を、ほかならぬ自分自身に適用したところから始まりました。前提はこうです。私は、私自身の目的・目標にも気づいていない。だから大きな目的は定めない。日々、小さな目的を設定し、翌日には壊して立て直す。その繰り返しだけがあります。私はこの姿勢を「purpose-last（目的を後に置く）」と呼んでいます。PoC（概念実証）ですらありません。まず積む。意味は、後から拾う。移動のログも、健康の記録も、車のセンサーの値も、意味の重なりを問わずに、ただ同じ器へ入れていきました。共通しているのは時刻（タイムスタンプ）だけ。移動系と健康系のあいだに、意味のうえでの関係は、ほとんどありません。ここが逆説の核心です。もし目的を先に決めていたら、この二つは決して同じ器に入らなかった。目的志向で正しく設計すれば、移動は移動のシステム、健康は健康のシステムとして、きれいに分かれて設計されるはずです。そして二度と出会わない。目的を決めなかったからこそ、無関係なはずのものが、時刻という一点で隣り合わせになりました。もちろん、これは無目的な溜め込み（ホーディング）ではありません。大きな目的は定めないけれど、動機だけは満ちています。データ主権、計測と移動の悦び、奪われた時間を取り戻すこと。目的は非常に頻繁に更新し続けますが、動機は動かない。「目的は更新し続ける、けれど動機は動かない」――この構えを、私は purpose-last かつ purpose-full（目的は後、しかし目的意識は満ちている）と表現しています。誤解を避けるために書き添えます。決めないのは"大きなゴール"のほうで、"小さな目的"は、むしろ毎日立てて、毎日壊します。データ管理の言葉に置き換えれば、スキーマ・オン・ライト（書き込む時点で構造と意味を固定する）ではなく、スキーマ・オン・リード（読み出す時点で意味を与える）に賭けた、ということです。生成AIは、この「後から意味を与える」作業を、劇的に安くしました。気づいたら、これだけ積み上がっていた目的を決めずに積んだ結果、何が溜まっていたのか。全数を実測してみて、自分でも驚きました。数字はすべて、推定なしの実測値です。全テーブルを合算すると、3,356万行（正確には 33,564,441 行）。うち健康・環境・電力などの時系列データが 2,751万行で、その 97.1% は、あるヘルスケアアプリからの自動書き出しでした。移動の点（GPS）が 526万行、車のセンサーが 71万行。写真は、公共の地図サービスへ投稿したものが 11,710 枚、手元に残っている本体は 115,187 枚・約 803GB あります。最も古い実データは 2012年、写真は撮影日ベースで 2009年まで遡り、時系列としては 14年分になります。

システムマネジメントアンドコントロール（SMCL）／野村隆昌

23/08/2026

ヴァイブコーディングの3万行を常時稼働させ、毎日20万件以上のデータを集める（第1回）

―― 「目的は、後から決める」は、プロダクトマネジメントの本質であるシステムマネジメントアンドコントロール（SMCL）／野村隆昌先日、JDMC（日本データマネジメントコンソーシアム）の「生成AIによるデータ管理研究会」で、ひとつの実践報告をしました。個人が、生成AIのエージェントたちと一緒に、毎日データを積み上げ続けている――そういう、少し変わった話です。反響が大きかったので、3回に分けて書き残しておきます。第1回は「プロダクトマネジメントの話」として。第2回は「チーム運営と心理的安全性の話」として。第3回は「関係と感情の話」として。同じ出来事を、三つの角度から見ていきます。まず断っておくと、私はITの専門家ではありません。正確には、かつてはそうでしたが、いまは違います。30年ほど前まではサーバやセキュリティのエンジニアでした。しかし2000年代初頭に、作る側から「作らせる側」――プロジェクトマネジメントやDX推進の側へ越境しました。以来20年、私は文章以外のものを、自分ではほとんど作れませんでした。データベースを設計した経験も、日常的にコードを書く習慣もありません。その私が、いま毎日、20万件を超えるデータを積み上げています。しかもその大半は、生成AIに書かせたコード――いわゆる「ヴァイブコーディング」で組んだ、約3万行の仕組みが、常時動いて集めています。なぜそんなことになったのか。その入口が、今日の話です。「私のデータなのに、統合できない」きっかけは、ある苛立ちでした。私は昔から、測ることが好きです。両腕に腕時計をしているのは、センサーが違えば取れる値も違うからです。体重も血圧も古くからデジタルで記録し、一時は血糖値を24時間、2週間にわたって連続で測っていました。食事の記録は、糖質制限をやり過ぎた反省もあって、もう10年以上続いています。地図と移動も、偏愛しています。これは新入社員の頃、トンネルの現場で「絶対座標で世界を捉える」感覚を叩き込まれたことが原点かもしれません。ついでに言えば、最近は地図アプリの多くが「進行方向が上」を既定にしていて、私はあれで、どうにも方向感覚が狂います。地図は、常に北が上であってほしい。世界の中心は私ではなく、私が世界の中を動いている――そういう感覚なのだと思います。つまり私は、放っておいても自分に関するデータが溜まっていく人間です。ところが、いざそれを使おうとすると、壁にぶつかりました。血圧計のメーカー、スマートウォッチ、運動アプリ、食事記録アプリ――どれも少しは連携できても、基本は各社のなかで閉じています。「私のデータ」のはずなのに、私が自由に統合できない。この「統合できなさ」は、いまデータ管理に関わる方なら誰もが直面しているテーマです。企業では相互運用性やデータ主権として語られます。私はそれを、たった一人分の、極めて個人的なかたちで体験していました。欲しかったのは、立派な画面でも分析ダッシュボードでもありません。「画面はいらない。データを、開けてくれ」。それが、すべての出発点にある動機でした。目的は、後から決める ―― それが本質です私たちはよく「まず Why（なぜ）を決めよ」と言います。目的を定め、仮説を立て、検証する。それ自体は正しい。けれども現場で本当に効くのは、もう一歩踏み込んだ規律だと、私は考えています。顧客は、自分の痛みも、欲しいものも知らない。だから、大きなゴールを先に固めてはいけない。小さな目的を日々立て、翌日にはどんどん修正していく。目的を後から決めることは、プロダクトマネジメントからの逸脱ではなく、その本質です。顧客を置き去りにして先に目的を固めた「良いプロダクト」ほど、たちの悪いものはありません。それこそが、目的が先にあることの典型的な悪例です。今回のシステムは、この原則を、ほかならぬ自分自身に適用したところから始まりました。前提はこうです。私は、私自身の目的・目標にも気づいていない。だから大きな目的は定めない。日々、小さな目的を設定し、翌日には壊して立て直す。その繰り返しだけがあります。私はこの姿勢を「purpose-last（目的を後に置く）」と呼んでいます。PoC（概念実証）ですらありません。まず積む。意味は、後から拾う。移動のログも、健康の記録も、車のセンサーの値も、意味の重なりを問わずに、ただ同じ器へ入れていきました。共通しているのは時刻（タイムスタンプ）だけ。移動系と健康系のあいだに、意味のうえでの関係は、ほとんどありません。ここが逆説の核心です。もし目的を先に決めていたら、この二つは決して同じ器に入らなかった。目的志向で正しく設計すれば、移動は移動のシステム、健康は健康のシステムとして、きれいに分かれて設計されるはずです。そして二度と出会わない。目的を決めなかったからこそ、無関係なはずのものが、時刻という一点で隣り合わせになりました。もちろん、これは無目的な溜め込み（ホーディング）ではありません。大きな目的は定めないけれど、動機だけは満ちています。データ主権、計測と移動の悦び、奪われた時間を取り戻すこと。目的は非常に頻繁に更新し続けますが、動機は動かない。「目的は更新し続ける、けれど動機は動かない」――この構えを、私は purpose-last かつ purpose-full（目的は後、しかし目的意識は満ちている）と表現しています。誤解を避けるために書き添えます。決めないのは"大きなゴール"のほうで、"小さな目的"は、むしろ毎日立てて、毎日壊します。データ管理の言葉に置き換えれば、スキーマ・オン・ライト（書き込む時点で構造と意味を固定する）ではなく、スキーマ・オン・リード（読み出す時点で意味を与える）に賭けた、ということです。生成AIは、この「後から意味を与える」作業を、劇的に安くしました。気づいたら、これだけ積み上がっていた目的を決めずに積んだ結果、何が溜まっていたのか。全数を実測してみて、自分でも驚きました。数字はすべて、推定なしの実測値です。全テーブルを合算すると、3,356万行（正確には 33,564,441 行）。うち健康・環境・電力などの時系列データが 2,751万行で、その 97.1% は、あるヘルスケアアプリからの自動書き出しでした。移動の点（GPS）が 526万行、車のセンサーが 71万行。写真は、公共の地図サービスへ投稿したものが 11,710 枚、手元に残っている本体は 115,187 枚・約 803GB あります。最も古い実データは 2012年、写真は撮影日ベースで 2009年まで遡り、時系列としては 14年分になります。

―― 「目的は、後から決める」は、プロダクトマネジメントの本質であるシステムマネジメントアンドコントロール（…

18/08/2026

2026年8月18日羽鳥会特別回のご案内 ── 目的を決めずに、AIエージェント9体でプロダクトを作る

羽鳥会とは羽鳥会は、弊社のトレーニングを受講された方が、ご自身の意思で参加される勉強会です。会社に言われて出席する研修ではありません。受講後も学び続けたい、現場で試したことを持ち寄って話したい——そう思われた方が、自分で決めて集まる場です。以前は定期的に開催していましたが、ここ最近は不定期の開催になっています。対話（Dialogue）を重視します羽鳥会の中心にあるのは、講義ではなく対話です。一方向に情報を流す時間を最小にして、参加者どうしが言葉を交わす時間を最大に取ります。人の話を聞いて、自分の言葉で返す。その往復の中で、自分が何を考えていたのかが初めて分かる——という経験を、この会では大事にしています。そのため Zoom 開催時は、顔出しと音声の参加を必須としています。聞くだけの参加はご遠慮いただいています。ただし、ご家庭の事情や移動中など、一時的にカメラ・マイクをオフにしていただくのは構いません。日常の中で参加していただくことが前提の会ですので、そこは柔軟に運用しています。参加者を限定している理由羽鳥会は、私のファシリテーションをご存じの方に限定して開催しています。理由は2つあります。ひとつは時間の節約です。グラウンドルールの説明、自己紹介、進め方のすり合わせ——初対面の場ではどうしても必要になるこれらの時間を、丸ごと本題に回せます。もうひとつが、より本質的な理由で、心理的安全性への取り組みです。対話の質は、参加者が「ここでは何を言っても大丈夫だ」と感じられるかどうかで決まります。互いの人となりと、進行役の癖を知っている人だけの場にすることで、その土台を最初から確保しています。うまくいかなかった話、失敗した話が出てくるのは、この土台があるからです。飲みながら、食べながらで構いません飲食は自由です。お酒も自由です。夜19時からの会ですので、夕食をとりながら、あるいは一杯やりながら参加していただいて構いません。カメラに映って困るものでもありませんし、そのほうが対話は動きます。 PDU は、ご自身で申請してください参加された時間について、PDU は各自で自己申請していただきます。主催側で一括申請することはしません。申請区分や時間数の扱いも、ご自身でご判断ください。これは手間を省いているのではなく、羽鳥会の本来の姿です。会社に言われて出るのではなく、自分の意思で参加する会です。そこで得たものをどう扱い、どう記録するかも、ご自身で決めていただく。参加の入口から出口まで、一貫して自律的な場でありたいと考えています。今回のテーマ ── 目的を決めずに、AIエージェント9体でプロダクトを作る最近よく聞かれます。「AIエージェントを何体も同時に動かすと、何ができるんですか？」正直に答えます。わかりません。いま、9体のAIエージェントが動いています。ブラウザの中に1体、自宅サーバに1体、Macに1体、車の中に3体、別のPCに1体、ポケットの中のGPSロガーに1体、そしてクラウドに1体。全員が1本のチャットに参加していて、人間は私ひとりです。集まったデータは、2012年から14年ぶんで約2,600万行。毎日およそ21万件が、勝手に流れ込んできます（2026年8月14日時点の実測）。で、これで何をするのか。決めていません。企画書はありません。要件定義もありません。成功基準もないので、失敗のしようもありません。始まりは「地図が好き」と「測るのが好き」の2つだけでした。「目的がないこと」と「いい加減であること」は、別物です今回いちばんお話ししたいのはここです。目的はない。けれど、役割分担も、独立した検証も、権限の最小化も、間違いの即時撤回も、全部きちんと回っています。実際に効いているコツは、驚くほど地味です。合意したルールは、その場で Markdown に書かせる（口頭の合意は、セッションが切れたら消えるので）実装する役と、検証する役を分ける...

羽鳥会は、弊社のトレーニングを受講された方が、ご自身の意思で参加される勉強会です。

04/08/2026

https://www.meridionalis.com/raci-accountability-ai-agents/

AIエージェントがチームに加わる時代、RACIと説明責任はどう設計すべきか。PMI公式ブログの要点を、PMP試験にもつながる実務目線で解説します。

有限会社システムマネジメントアンドコントロール

24/08/2026

24/08/2026

23/08/2026

23/08/2026

23/08/2026

23/08/2026

18/08/2026

04/08/2026

住所

ウェブサイト

アラート

事業に問い合わせをする

ショートカット

共有する

カテゴリー

掲載情報の削除リクエスト