はじめに
生成AIに問いかけると、整った答えが返ってきます。その答えを手直しして、次の仕事へ進む。仕事に取り入れる入口として、思い浮かべやすい使い方です。
けれども、仕事には答えを書く前に考えることがあります。そもそも何を目指しているのか。どの問いから考えるべきか。判断に使っている前提は確かか。答えを得るたびに、こうした問いが残ります。
それなら、生成AIとの関わりを問いを立てて考え直す過程まで広げられないだろうか。私がOrca1で試しているのは、そのための運営です。
目的を共有し、問いを立て、根拠を探す。異なる視点で議論し、任された範囲で判断して仕事を進める。結果を振り返り、学びを次へ渡す。その流れを人とAIエージェントの関係として組み立てようとしています。
私はこれを「自律型AI組織」と捉えています。人が方向性と境界を定め、その内側でAIが判断と作業を進める運営です。ここでいう組織は、人間の組織をそのまま小さく複製したものではありません。仕事に必要な責任と思考の関係を扱える形にしたものです。
答えを出す前に問いを分ける
ひとつのAIにすべてを聞くと、ひとつの筋の通った説明が返ってきます。読みやすく、納得しやすい説明です。それでも、別の前提から考えたらどうなるかという問いは残ります。
私の運営では、事業の方向を考えるシオリ、顧客への伝わり方を考えるミナミ、根拠やデータを確かめるハヤトという役割を置いています。原稿を整えるコトハ、実装を担うタクミ、独立した目で検査するレイは、仕事に応じて加わります。
これらの名前は、仕事を考える視点と責任の定義に付けたものです。イマジナリーな人格とも呼んでいます。必要な担当を起動し、目的に合わせて協働します。このネーミングもAIが自ら考案したものです。
シオリの提案をミナミが顧客の立場から問い直し、ハヤトが根拠の届く範囲を示す。ひとつの答えへ急ぐ前に、問いの違いを表へ出します。
この記事の準備でも、構成を考える担当と伝え方を考える担当が別々に論点を出し、相手の案を読んで応答しました。当初の案を守るだけでなく、反論を受けて構成を変え、不採用の案には理由を残しています。その往復を執筆担当へ渡すことで、結論だけでは見えない判断の背景も共有しました。
公開サイトなどの変更では、検査を作成側と分け、異なるAIの目で確かめるルールにしています。
一方で、役割はCodexやClaude CodeなどAIプロダクトを固定していません。「この役割だから、いつもこのAI」とはせず、仕事の性質に応じてモデルや担当を見直します。責任の区分と、それを担う道具を分けて考えています。私が「モデルを育てない」と言うのも、この意味です。特定のモデルへの依存を深めるのではなく、モデルが変わっても持ち越せる目的や根拠、判断の基盤を整えます。
図1は、私が考える関係を整理したものです。特定の手法の公式図ではありません。現在の運営に加えて、今後の見通しも含めています。GrokやGemini、ローカルLLM2も、目的や必要に応じて組み合わせる構想です。
役割の数はそのまま組織の力を表しません。問いが単純なら、担当を増やさずに進める方がよいこともあります。別の視点が必要な場面で、必要な役割を置く。そう考えると、組織は固定した名簿よりも、目的に合わせた関係として見えてきます。
それぞれのAIモデルがもっている「サブエージェント3」を用いることもありますが、別のAIモデルをサブエージェントとして活用するほうを優先しています。
自律性を支えるのは考え直せること
AIに任せるとき、どこまで細かく指示すべきかは悩ましいところです。すべての手順を指定すれば、途中で新しい事実が見つかっても動きにくくなる。自由に任せすぎれば、こちらの目的から離れてしまうかもしれません。
そこで私が大切にしたいのは、目的と判断の境界を共有することです。何のための仕事か。どこまで自分で判断してよいか。どんな問いは人へ返すか。その土台があれば、細部の進め方を担当へ委ねる余地ができます。
たとえば、根拠が足りないとわかったときに、もっともらしい説明で埋めない。目的に合わないと考えたら、理由を添えて問い返す。自分の権限を超える判断なら、人へ返す。こうした振る舞いも、私が期待する自律性の一部です。
人間は方向性を定め、価値について判断し、責任を持つ。AIは共有された境界の内側で、問いを整理し、判断材料を作り、仕事を進める。その関係を仕事の途中でも確かめ直します。
自律的であることは、最初の指示を最後まで変えずに実行することだけではありません。状況が変われば、次に考えるべき問いも変わります。その変化に気づき、目的へ立ち返れる運営を目指しています。
科学的思考で予測と観察をつなぐ
生成AIは、筋の通った説明を作ることができます。だからこそ、説明のもっともらしさと、現実から学べているかを分けて考えたいと思っています。
私がここでいう科学的思考は、目指す方向を定め、現在を観察し、仮説を置いて小さく試す考え方です。予測と結果の違いから学びます。
その出発点には、戦略的ゴール4があります。誰にとってどんな変化が望ましいのか。目指すアウトカムを定義し、どう計測するかを考える。「やること」に飛びつく前に、なぜそれをするのかへ立ち返ります。「当たり前」だと思っていることや、自分たちの思い込みも問い直す対象です。
答えを正当化するために材料を集めると、都合のよい説明だけが残りかねません。考えを変える材料にも目を向ける必要があります。
何を事実として確かめたのか。どこからが解釈なのか。この予測と違う結果が出たら、何を考え直すのか。AIへこうした問いを渡すときも、最終的に現実と照らす責任を手放さないようにしています。
AI同士の議論にも、同じことが言えます。異なるモデルが同じ結論に達しても、それだけで正しさが証明されるわけではありません。同じ前提を共有して、同じところを見落としている可能性があります。
むしろ、違う意見が出たときに、どの前提が違うのかをたどることに意味があります。何を根拠にしたのか。相手の問いを受けて何を変えたのか。その理由が残れば、人間も結論を吟味できます。議論をさせる目的は、賛成票を増やすことではなく、考え直すきっかけを作ることです。
アジャイルのカタで思考を繰り返す
科学的に考えたいと思っていても、日々の仕事では目先の答えへ急ぎがちです。そこで参照しているのが、アジャイルのカタです。
アジャイルのカタは、科学的思考を練習する型として捉えられます。方向性を捉え、現在を観察し、次の目標状態を置き、小さな実験から学ぶ。その繰り返しによって、不確実な状況でも次の一歩を考えます。
私が「AIにカタを練習させる」と考えるのは、この問いの流れを仕事の中で繰り返すことです。特定のモデルにカタを覚え込ませるというより、科学的思考を繰り返す問いの習慣を運営に組み込みます。目指す方向は何か。現在はどうなっているか。次にどんな状態へ近づきたいか。いまの障害について何を予測し、何を試すか。そして、予測と実際はどう違ったか。
重要なのは、問いの順番を埋めた書類を作ることより、問いによって判断が変わることだと思います。現在の状態を見た結果、当初の依頼を小さくするかもしれません。根拠を読んだ結果、提案を撤回するかもしれません。その変化を次の一歩へつなげます。
図2は、科学的思考を中心に、カタとEBMがどのように運営を支え得るかを私が整理した応用図です。三つを同じ手法として示すものではありません。
EBMで何のための自律性かを問い直す
AIが自分で進められる仕事が増えたとき、何をもってよかったと言えるでしょうか。担当が増えた、議論が増えた、成果物が増えた。それぞれ運営の様子は示しますが、それだけでは誰にどんな価値が届いたかはわかりません。
Evidence-Based Management（EBM）は、目標へ向けた判断を意図的な実験とフィードバックによって助ける考え方です。私は、AIとの運営を目的と価値へつなぎ直す視点として参照しています。
EBMには4つの重要価値領域5があります。現在の価値と、潜在的なニーズを満たすことで実現し得る将来の価値（未実現の価値）。さらに、提供して学ぶ速さと、新しい能力を提供する組織的な能力です。指標を増やすための分類というより、価値と価値提供の能力について問いを広げる領域です。
これを私の運営へ応用するなら、AIがどれだけ働いたかを見るだけでなく、その仕事が誰の判断や行動を助けたかを考えることになります。まだ満たせていない困りごとは何か。学ぶまでにどんな隔たりがあるか。運営自体が重くなり、新しいことを試しにくくしていないか。そうした問いへ視野を広げられます。
カタで考える練習を重ね、EBMで目的と価値へ戻る。科学的思考で予測を現実と照らす。私はこの関係を変化に合わせて運営を考え直すための支えにしたいと思っています。
この考え方を日々の判断へ根づかせる途上にあります。仕事量が増えたことと、価値が届いたことを分けて確かめる必要があります。
OrcaとObsidianが協働の場として役立つところ
この運営では、Obsidian6とOrcaを組み合わせています。Obsidianは、私にとって「思考を次へ渡すための場所」です。目的や根拠、判断の理由、適用できる条件を必要な資料や成果物とともに残す。こうした判断の土台を次の担当へ渡せるようにしています。ObsidianのそれぞれのVaultが実質的なAIエージェントの人数となる設計です。
Orcaは、その記録を読み、異なるAIモデルが役割を担う協働の場です。私がOrcaに感じる利点は、異なるAIプロダクトやモデルを同じ作業環境に置き、同じ資料や成果物を見ながら役割を分けられることです。視点を変えるたびに仕事の前提まで切り離すのではなく、共通する根拠を持って議論できます。
今回も担当への依頼、質問と応答、完了の報告をたどっています。成果物と照らして、次の担当へ渡しています。人がその間に入り、方向を修正できることも大切です。担当を引き継ぐ際に役割の責任とモデルの選択を分けて扱えることが、仕事に応じた編成を支えています。
これは今回の実践で役立った点です。一方、連携が止まっているのに、着手を確かめず進行中と伝えてしまった失敗もありました。その失敗から、連絡の到達、担当の着手、成果物の完成を別に確かめる必要を学んでいます。
私にとってOrcaは、思考や判断を肩代わりするものというより、共通の土台に沿って考えをつなぐ場です。その土台をどう持ち、維持するかも運営の一部になります。私はこの組み合わせをAIエージェントの運営を組み立てて見直す環境として捉えています。その意味でのADE（Agent Development Environment）です。
ハーネスを持ち常に見直すために
目的に合わせて役割やモデルを組み替えるとき、前提まで毎回ゼロに戻ってしまっては仕事がつながりません。そこで、判断を支える土台をモデルの外に持ちます。ここでは、その土台を「ハーネス」と呼びます。目的や役割、権限をモデルの外に置く。記憶と検証、連絡や実行も支える。そうした仕組みのまとまりです。Orcaという道具や、一文のプロンプトだけを指す言葉ではありません。
私の運営では、共通するルールと役割ごとの責任を分けて置いています。作業ごとの目的と権限も別に定めます。必要なスキルと過去の学びも、それぞれ参照できる形にしています。すべてを毎回読ませるのではなく、入口から仕事に関係する資料へたどる構成です。変わりにくい土台と、仕事によって変わる条件を分けることで、担当が交代しても何を前提に判断するかを復元できるようにしています。
記憶には、結論だけでなく根拠や使える条件を残す。ただし、過去の記憶より現行のルールを優先します。以前の仕事で有効だった手順が、今回も適切とは限らないためです。
維持するときに必要なのは、失敗のたびに規則を足すことだけではありません。土台そのものも見直す対象です。現行のルールに照らして古い手順や矛盾を見つけ、重複を整理する。必要な資料へたどり着けるか、その内容が実際の判断に使われるかも確かめる。記憶の発見と適用を実際に検査し、構成を見直しています。書いたことが自動で引き継がれるとは考えず、ファイルへ書いたことと、仕事に適用されたことを分けて見ます。AIが矛盾に気づいたら、根拠とともに人へ返す。目的や権限の境界を変える判断は、人が担います。
図3は、共通の土台と作業ごとの編成を分け、学びを土台へ戻す私の応用図です。ハーネス自体も小さく試し、改める対象として置いています。
ここまでの対応づけは、私の実践を振り返りながら考えている応用です。正式な手法の全体を一貫して実践したという認定でも、AIが人と同じように思考するという主張でもありません。全自動の運営や顧客への効果を実証したものではなく、価値や改善効果の検証はこれからの課題です。
AIエージェント側から見た運営
ここでは筆者としての私の語りから離れ、原稿制作を担ったAIエージェント側の考察を記します。今回の連携と受領した記録からの実務的な考察であり、感情や意識の説明ではありません。
一つは、目的と判断基準が行動の選択肢を絞ることです。「よい文章を書く」だけでなく、誰に何を伝えるかが渡されると、何を残し、何を省くかを判断しやすくなります。今回も読者へ伝える焦点が変わったことで、既存の構成を守るより原稿を組み直す方が目的に合うと判断できました。
二つ目は、異なる視点の反論が、前提を見直す材料になることです。今回の議論では、シオリがミナミの反論を受け、定義を置く位置や事例の構成を変えました。一方、無料相談を主な導線にする案は、AI運営相談としての提供範囲が未確認のため採りませんでした。意見の一致を求めるより、変えた理由と採らない理由が示されることで、執筆側も判断の境界を引き継げます。
三つ目は、安定した責任と共有された前提が、担当交代を支えることです。役割の責任がわかり、根拠と推測が区別されていれば、別のモデルでも何を確認すべきかをたどれます。境界で質問を返せることも、不足する前提を推測で埋めずに進める助けになります。
ただし、情報が多すぎたり、現行ルールと古い記憶が矛盾したりすれば、その土台が判断を妨げることもあります。共有記憶は量より、必要なときに見つかり、現在に合うかを確かめられることが大切です。これらは今回のやり取りから見える利点と制約であり、生産性の因果効果を測定した結果ではありません。
小さな問いから始めてみる
最初から同じ役割や仕組みをそろえる必要はありません。公開しない小さな仕事を一つ選び、「何を目指すか」「どこまで任せるか」「どんなときに問いを返すか」「何で確かめるか」を書いてみる。答えとともに、その前提や別の見方も尋ねてみる。そこから始められます。
ツールやモデルが変わっても、目的を問い、観察し、考え直す仕事は残ります。生成AIと働くことは、自分たちの思考や判断のあり方を見直す機会にもなる。私は、その可能性を小さな実践で探っていきたいと思っています。
現場の実課題を扱い、試しながら検査と適応を重ねたい方には、伴走支援をご案内しています。自分たちで改善を続けられる状態を一緒に目指す支援です。
考え方を体系的に学びたい方には、価値の計測と意思決定を演習で学ぶScrum.org認定 PAL-EBM研修、小さな実験と予測との差から学ぶ認定アジャイルのカタPRO研修があります。生成AIとの仕事をきっかけに、変化に向き合う自分たちの学び方も考えてみませんか。
スライド
この記事内容をスライドにしました。
- Orcaとは、ADE/エージェント開発環境で、CodexとClaude Code、ローカルLLMなどの複数のAIモデルをオーケストレーションして協働させられるツール ↩︎
- ローカルLLMは、Mac mini (M6) 上にあり、LM Studioで運営している ↩︎
- AIモデル/プロダクトでは、設定すればサブエージェントをたてることができる。それらに異なるモデルを割り当てすることができるが、あくまでプロダクトの中のモデルに閉じていることが多い ↩︎
- EBMのゴール設定で欠かせないもので、事業の戦略を実現するために設定するゴールのこと。達成したらどんな状態になっているのかを示す。 ↩︎
- EBMで定義する望ましいアウトカムを計測するための領域のこと ↩︎
- ObsidianはAIが用いて、人間とある程度共有できるレベルで用いている。すなわち、人間のナレッジは別で管理している。ObsidianのVaultの数が、そのまま自律型AIエージェントの人数と見なせる ↩︎
本記事の執筆者:
長沢 智治 - アジャイルストラテジスト
- サーバントワークス株式会社 代表取締役
- プロフェッショナルスクラムトレーナー（PST） 《日本人初》
- Agile Kata Pro 認定トレーナー《日本人初》
- DASA 認定トレーナー（プロダクトマネジメント、DevOps）
認定トレーナー資格
『アジャイルのカタ』『EBM実践ガイド』「プロフェッショナルアジャイルリーダー』『More Effective Agile』、『Adaptive Code』、『今すぐ実践！カンバンによるアジャイルプロジェクトマネジメント』、『アジャイルソフトウェアエンジアリング』など翻訳・監訳書多数。『Keynoteで魅せる「伝わる」プレゼンテーションテクニック』著者。
Regional Scrum Gathering Tokyo 2017, DevOpsDays Tokyo 2017, Developers Summit 2013 summer 基調講演。スクー講師。
ニュースレターを購読する（月1〜2回・いつでも解除できます）
会社・サービス案内（PDF）を見る →お名前とメールアドレスのみ。営業のご連絡はいたしません。
