生成AIニュース 2026年9月19日

AIを「使い倒す」先にある問い：Human + AI から Outcome First へ

AIを使い込んでいくと、ある時点で「この仕事、そもそも必要だったか」という問いに行き着く。

Qiitaに投稿された@nashomaru__（なしょまる）さんの記事「AIを使い倒した先にある組織論：Human + AI から Outcome First へ」は、その問いに対して三つの段階で答えを整理したものだ。技術論というより組織論として読める内容で、AI活用の議論が「何のツールを使うか」から「業務をどう設計するか」へとシフトしている流れに、言葉を与えている。

三つの段階を整理する

記事では、AI活用と組織設計の関係を「Human + AI」「Human or AI」「Outcome First」という三段階で捉えている。順を追って整理する。

Phase 1：Human + AI

最初の段階は、人間がAIに指示を出し、AIが作業を支援するというシンプルな構造だ。コードを書いてもらう、プルリクエストをレビューしてもらう、ログを解析してもらう、技術調査やドキュメント作成を任せる。人間の知識や経験をAIに伝えながら、一緒に仕事を進めるかたちだ。

この段階でAIを使い続けると、ある問題に気づく。毎回同じ説明を繰り返しているということだ。「このプロジェクトでは、このルールに従う」「仕様はこのドキュメントにある」「この設計を選んだのには、こういう経緯がある」「この顧客には、こういう事情がある」──人間同士なら暗黙の了解で済んでいたことも、AIに任せるには言語化が必要になる。

記事ではこれを「コンテキスト」と呼んでいる。AI活用は、組織にどれだけ暗黙知があるかを知るきっかけにもなる、という指摘は刺さる。

Phase 2：Human or AI

コンテキストを毎回説明しているうちに、「あらかじめ参照できる形で残したい」という動機が生まれる。個人の頭の中にあった情報を、組織で共有する情報へと移していく段階だ。

具体的には、README、設計上の判断とその理由を残すADR（Architecture Decision Record）、AI向けの作業指示を記したCLAUDE.mdやAGENTS.md、コーディング規約、成果物の受け入れ基準（Acceptance Criteria）、運用手順書（Runbook）、設計書（Design Document）といった文書群が挙げられている。

こうした整備が進むと、「あの人に聞かないと分からない」仕事が「この文書を読めば進められる」仕事に変わっていく。そして、仕事によっては「人間が担当する」「AIに任せる」を選べる状態になる。これが「Human or AI」だ。

重要な点は、この整備はAIだけのためではないということだ。新しいメンバーの立ち上がりが速くなり、担当者が変わっても引き継ぎがしやすくなる。AIに伝わるように情報を整理することが、人間の働きやすさにも直結する。

Phase 3：Outcome First

ここが記事の核心だ。

Human or AIの発想は、「既存の仕事をそのまま続ける」ことを前提にしている。「毎週、報告資料を作る」という仕事があるとき、Human or AIの考え方では「人間が作るか、AIに作成を任せるか」を検討する。しかし、その仕事の目的が「経営者がプロジェクトの状況を把握し、必要な意思決定を行えるようにすること」なら、報告資料という形式にこだわる必要はない。ダッシュボードで確認できれば十分かもしれないし、異常が起きたときだけ通知すれば足りるかもしれない。目的を満たせるなら、毎週資料を作る仕事自体をなくす選択もある。

Outcome Firstでは、仕事を設計するときに「何を実現したいのか」を起点にする。現状と目指す状態の差を確認し、その差を埋めるために何を変えるか、判断や実行に必要な情報は何かを整理してから、実行手段を選ぶ。人間が担当する、AIに任せる、従来のソフトウェアで自動化する、ルールを見直す、外部サービスを使う——これらを組み合わせることも、不要な業務を廃止することも選択肢に入る。

「Human or AI」の落とし穴

ここで一歩引いて考えると、この枠組みは「AI活用を突き詰めると、仕事の再設計に行き着く」という当たり前のことを、段階を追って示したものだとも読める。

ただ、当たり前のことが実務でできていないから論じる意味がある。

「AIで何ができるか」から業務改善を考えると、今ある仕事をそのままAIに置き換えようとしがちになる。報告資料の例で言えば、資料作成を速くすることに意識が向く。担当者をAIに替えても、目的を問い直さなければ、不要な仕事を速く処理しているだけになりかねない。

この「担当を替えるだけでは本質は変わらない」という指摘は、AI活用の議論でよく見落とされる部分だ。ツール選定の話で終わると、そもそもその業務が必要かという問いに至らない。

ここからは見方だが：AIの「使いにくさ」が組織の診断装置になっている

記事の中で個人的に最も面白いと感じた指摘は、「AIがうまく働かない理由から、組織の課題が見える」という部分だ。

AIに仕事を任せようとしてもうまくいかないとき、その原因を探ると、必要なドキュメントがない、どれが最新の情報か分からない、判断基準が曖昧になっている、情報が散在している、担当者の暗黙知に頼っている、責任範囲が明確になっていない、といった組織側の問題が見つかることがある。

これらは、人間が経験や対話で補ってきた問題でもある。AI導入の手前でつまずいているとき、実は「組織が整っていない」ことを可視化しているだけ、ということが少なくない。

AIを鏡として使う、とでも言えばいいか。うまくいかない場所を責めるのではなく、そこを「仕事の進め方を見直す手がかり」として使う発想は、実務的に使える視点だと思う。

もうひとつ注目したいのは、記事の終盤にある「AI活用という言葉が消えていく」という展望だ。業務システムでデータベースを使うたびに「DB活用」と呼ぶわけではないように、AIも必要に応じて選ぶ技術の一つになる——という見方は、現在の「AI活用！」というトーンへの静かなカウンターだ。その状態になったとき、組織設計の議論はもっと地に足がついたものになる。道具の話ではなく、目的と業務の話として。

実務への示唆：何から手をつけるか

では実際、この枠組みから何が引き出せるか。

ドキュメント整備は「AIのため」と言い訳しながらやるとうまくいく

組織でのドキュメント整備は、必要だと分かっていながら後回しになりやすい。「AIに任せるため」という理由は、そのための動機を作るのに使いやすい。README、ADR、受け入れ基準——これらを整えることは、AIより先に人間の仕事を楽にする。

AI導入で詰まった場所を「組織の診断」として使う

AIがうまく動かない理由のリストを見直してほしい。「判断基準が曖昧」「情報が散在している」「暗黙知に依存している」——これはAIの問題ではなく、組織運営の問題だ。AIを導入して初めてそれが表面化するなら、AI導入は「診断のきっかけ」として価値がある。うまくいかないことを無駄にしないためにも、「なぜAIが動かなかったか」を記録しておく習慣があると、後から使える。

測るべきはAI利用率ではなく、目的の達成度

AI利用率や導入数をKPIにしていると、業務をなくすことで得られた改善を捉えにくくなる、と記事は指摘している。これは本質的な問いだ。「毎週の報告資料をAIで5分で作れるようになった」より「毎週の報告資料をなくしてダッシュボードに切り替えた」のほうが、目的の達成に近い可能性がある。前者はAI活用の成果として計上しやすいが、後者のほうが組織としては正解だ。何を成果として測るかを先に決めておかないと、ツール活用の最適化に走って業務改善を見落とす。