社員がAIアプリを作れる時代、なぜ「ポジション管理」が必要になるのか

「業務で困っているなら、自分専用のAIツールをサクッと作ればいい」

生成AIの登場によって、社内アプリ開発のハードルは驚くほど下がりました。かつてなら外部のシステム会社へ見積もりを取り、要件定義に数か月をかけ、社内調整を経てようやく納品されていたようなツールが、いまや現場の担当者の手で、わずか数時間や数日で形になってしまう。このスピード感と圧倒的な自由さは、間違いなく素晴らしい進化です。

私自身、現場の課題を一番よく知っている当事者が自ら手を動かし、プログラミングやAIの力を借りてツールを組み上げていくスタイルこそが、これからの社内開発の主役になると考えています。私のような技術者（FDE：現場に併走してプロダクト開発を支援するエンジニア）や外部の専門家が果たすべき役割も、「すべてを代行して作ってあげること」ではなく「現場の人が自力で運用し、改善し続けられる状態まで伴走すること」へとシフトしています。

しかし、この「誰でも作れる素晴らしい世界」には、一つだけ大きな落とし穴が存在します。
作れる人が増えれば増えるほど、社内に静かな、そして深いカオスが広がり始めるのです。

失敗パターン：「また同じツール作ってるの？」野良アプリが増え続ける恐怖

社内でAIアプリが自由に作れるようになると、ほぼ確実に次のような現象が起き始めます。

営業チームが作った「商談メモ要約AI」があるのに、隣のカスタマーサクセスチームも全く同じ目的で独自の「顧客ヒアリングAI」を作り始める。経理部が独自に作った顧客管理データと、マーケティング部がツール内に保持している顧客リストの数値が食い違い、どちらが正しい正本データなのか誰にも分からない。さらに深刻なのは、作った当本人が部署移動や退職をした瞬間、そのアプリは誰もコードを触れない「野良アプリ」と化し、それでも業務で使われ続けている……という状態です。

課題は「アプリを作れない苦しみ」から、「アプリが無秩序に増えまくり、収集がつかなくなる恐怖」へと移っていきます。

このカオスを放置すると、せっかくの現場の工夫や熱量が、組織の足枷になってしまいます。かといって、「これからはすべてのアプリ開発を情報システム部が事前に審査・承認します」という昔ながらの中央集権管理に戻してしまえば、せっかく芽生えた現場のスピード感と自発性は完全に死んでしまいます。

作らせないのではない。野放しにもしない。
そこで必要になるのが、私が「ポジション管理」と呼んでいる設計の考え方です。

ポジション管理とは、「審査で止める」ことではなく「役割の境界を引く」こと

「ポジション管理」という言葉を聞くと、新しい社内ルールや面倒な管理業務をイメージされるかもしれません。しかし、私が意図しているのは「開発を止めるための審査」ではありません。

新しく作ろうとしているアプリが、「社内のどの問題を、誰のために、どの範囲まで解くものなのか」を、開発に着手する前の段階でクリアに見える化することです。

ここで一番重要なのは、アプリの「名前」に騙されないことです。
たとえば「営業AI」や「議事録AI」といった大雑把な名前だけでは、既存のアプリと重複しているかどうか判断できません。一口に「営業」と言っても、商談前の企業リサーチをするツールなのか、商談後の議事録を整形するツールなのか、見積書の承認を回すツールなのかによって、使う人も、扱うデータも、責任の所在もまったく異なります。

逆に、どれほど違う名前がついていたとしても、「同じデータソースから同じ判断を返している」のであれば、裏側のロジックやAPIは共通化できるはずです。

Microsoftが提供するローコードプラットフォーム「Power Platform」にも、社内に存在するアプリや自動化フロー、AIエージェントの全体像を横断的に把握するインベントリ（目録）機能が備わっています。また、アメリカのNIST（国立標準技術研究所）が定めた「AIリスク管理フレームワーク（AI RMF）」でも、組織内のAIシステムを可視化・一覧化し、それぞれの役割と責任を明確にし、定期的に見直して安全に廃止するプロセスをガバナンスの柱として掲げています。

ツールの規模や企業規模が違ったとしても、「何が社内に存在し、誰が管理し、どこまで影響を与えるのか分からないまま増やしてはいけない」という原則は、完全に共通しているのです。

コードを書く前に「1枚のシート」を置くだけで手戻りは劇的に減る

では、具体的にどうやってポジション管理を行えばいいのでしょうか。
私が最も効果的だと実感しているのは、「コードを一行も書く前に、作りたいものの概要を1枚の短いMarkdownノートにまとめる」という方法です。

大げさな企画書や何ページにも及ぶ稟議書を書く必要はありません。次のような最小限の6つの項目だけを、サッと埋めてもらうのです。

開発を始める前にこの1枚のシートを作成し、エンジニアや共通基盤の担当者（FDEなど）に見せて「数分間の対話」をする。たったこれだけのプロセスを挟むだけで、現場のスピード感を殺さずに、劇的な効果が生まれます。

「あ、その顧客データなら既に共通のAPIがあるからそこから引こう」「その文章要約機能、隣の部署が作ったアプリの部品をそのまま再利用できるよ」「これは個人用の実験ツールとして、独立した環境で試した方が安全だね」といったアドバイスを、作る前に渡せるからです。

アプリを作り終えた後に「実は同じものがありました」と判明して無理やり統合させるのは地獄です。作る前にほんの15分会話して境界線を引く方が、手戻りは何十倍も小さくなります。

すべてを1つの巨大システムにまとめるな。共通化すべきは「正本データ」だけ

社内でAIアプリが増えてくると、真面目なエンジニアや管理部門ほど「よし、バラバラのアプリをすべて統合して、1つの巨大な基盤システムにまとめよう！」と考えがちです。しかし、これは多くの場合失敗します。システムが巨大化・複雑化すると、現場が自分たちの都合に合わせて小さく改善する柔軟性が失われてしまうからです。

画面やユーザーインターフェースのすべてを統一する必要はありません。
共通化すべきなのは、画面ではなく「正本データ」と「認証・検索などの接続基盤」だけです。

私自身が理想と考えているのは、社内のドキュメントや顧客データを横断的に検索できる頑丈なナレッジ基盤（API）を中央に用意し、その上で現場の各部署が、自分たちの用途に特化した小さな「専用ツール」を自由に作るというアーキテクチャです。

同じ正本データにアクセスしながらも、営業部は「商談準備ツール」、管理部は「申請チェックツール」、制作チームは「要件定義補助ツール」として、自分たちが使いやすいUIで活用する。データを社内に複製・散乱させず、現場の体験だけを最適化する設計です。

このとき、FDEや社内エンジニアが果たすべきは「申請を弾く厳しい審査官」ではありません。社内アプリというパズル全体を美しく配置する「編集者」の役割です。

現場からの「こんなツールが欲しい」という個別リクエストをただ突っぱねるのではなく、会社全体の事業構造という地図の上に置き、「ここは共通の基盤に乗せよう」「ここは現場特有のツールとして独立させよう」と交通整理を行う。そのためには、コードが書けること以上に、会社が誰にどんな価値を提供していて、今後どの方向へ向かおうとしているのかという「事業への深い理解」が欠かせません。ビジネスの脈絡を無視して技術的な美しさだけで共通化してしまうと、組織図が変わった瞬間に全体が瓦解してしまうからです。

ポジションは固定せず、「状態」として生き物のように管理する

もう一つ大切なのは、一度決めたポジションを永久固定しないことです。アプリには「ライフサイクル」が存在します。

アプリの管理を、「個人の試作」→「チーム内で検証中」→「組織の共通機能」→「統合・廃止予定」というように、「現在の状態」としてダイナミックに管理するのがコツです。

状態が昇格・変更されるたびに、利用者数、管理責任者、参照するデータ範囲を見直し、隣接する他のアプリとの重複がないかをチェックします。
この運用であれば、個人が実験的に作る小さなツールに対して最初から重い書類提出を求める必要がなくなります。最初は個人環境で自由に遊ばせ、成果が出て「みんなに使わせたい」となったタイミングで、必要なガバナンスと保守責任をセットで引き受ける。ポジション管理とは固定された静かな台帳ではなく、事業の成長と変化をリアルタイムに映し出す「動く地図」であるべきなのです。

野良アプリを成長させる「段階的ガバナンス」6つのチェック基準

最初からすべてのアプリに厳しいセキュリティ審査や保守計画を義務付けると、現場の内製文化は即死します。
1人の社員が自分の作業を効率化するためだけに1日だけ使うツールと、社外の顧客データを扱い、30人のメンバーが毎日業務で使うツールを、同じ重さで管理する必要はどこにもありません。

Microsoftのガイドラインでも、個人向けに作成されたアプリが徐々に共有され、業務上の重要度が増したタイミングで、専用の共有環境へとステップアップさせ、所有権や運用サイクルを管理するという段階的なアプローチが推奨されています。

最初は軽やかに始め、影響範囲が広がるにつれて管理の綱を締め直す。
私なら、アプリの段階を切り替える際の判断基準として、次の6つのチェック項目を使います。

1. 同じ問題を解く既存のアプリやツールが、社内に他に存在しないか？
2. 顧客や案件などの「正本データ」を勝手に複製せず、正しく参照できているか？
3. 作成者本人が移動・退職しても、代わりに保守・運用できる所有者が決まっているか？
4. もしツールが誤作動・停止した場合、影響を受ける人と業務範囲を明確に説明できるか？
5. 利用ログを取り、継続的に改善や修正を行う仕組みが残されているか？
6. 将来的に他のアプリへ統合・置換・停止するための「引き際」の条件が決まっているか？

もし、このうち3つ以上に即答できないのであれば、そのアプリはまだ「個人用の試作環境（実験室）」に留めておくべきです。
逆に、すべての問いに明確に答えられるようになり、チームや部署のメンバーが日常的に使い始めたら、正式な「組織のアプリ」として登録し、保守体制と廃止条件まで含めて運用を引き受ける。この2段階のステップを踏むことで、現場の「自由な発想」と組織の「安全と責任」をしっかりと両立させることができます。

「作る力」ではなく「増えたものを整理する資産化の力」が問われている

AIの普及によってアプリの制作速度が爆発的に上がるこれからの時代、会社の競争力は「社内に何本のアプリがあるか」という数では決して測れなくなります。

本当に価値があるのは、「現場の知恵や困りごとをすぐツールとして形にできるスピード」と、「生まれたツールを野良化させず、組織共通の資産へと変えていく整理力」のバランスです。

もちろん、どのタイミングで「個人の試作」を「組織の資産」へ昇格させるべきかという境界線には、まだ絶対的な正解があるわけではありません。
単純な利用者数の多さだけでは測れないからです。使っているのがたった1人であっても、そのツールが止まると決算業務が丸ごと遅れるようなクリティカルな道具もあれば、100人が触っていても、最悪なくなっても困らない娯楽的な道具もあります。だからこそ、固定化された硬いルールではなく、事業へのインパクトと管理責任を定期的に見直す「しなやかな運用」が必要なのです。

社員が自分たちの手でツールを作ることを決して止めない。
その代わりに、誰が何を作っているかを互いに見えやすくし、共通のデータ基盤へ安全につなぎ、役割の境界線を美しく引いていく。そして、現場でたくましく育った成果だけを、組織全体で大切に引き受けていく。

これこそが、AI内製時代において、私たちが組織に設計すべき「最も優しく、最も強固な秩序」なのだと信じています。