内製アプリ開発を止めない、最初の受け渡しの設計
現場の業務を誰よりも知る担当者が、「この作業、自動化できたらすごく楽になるのに！」と思いつく瞬間があります。それは間違いなく、業務改善において最も価値ある一歩です。
しかし、そのアイデアを社内のナレッジベース（社内の情報や知識を集め、検索や他システムと連携できるようにした基盤）に繋ごうとした途端、急に話が進まなくなってしまう……そんな経験はないでしょうか。せっかくの熱意が途絶えてしまうのは、とてももったいないことです。
本稿では、現場発の内製アプリのアイデアを立ち消えさせず安全に実装へ繋げるために、私たちが実践している「最初の受け渡し」と「方針書」の設計をお伝えします。
なぜ最初の受け渡しで内製アプリが止まるのか
現場から「こういうアプリを作りたい」と相談を受けたとき、開発側が最初から「できるか、できないか」の二択だけで判定を下してしまうと、会話が途絶えてしまいがちです。一見迅速に見える可否の回答ですが、次のステップに進むための検討材料を何も残していません。
この原因は、現場と開発側が見ている景色の違いにあります。現場の担当者は「この画面から操作できれば業務が楽になる」という利用シーンに焦点を当てています。一方で開発側は「どのデータベースと連携し、どのようなアクセス権限（認可）でデータを守るべきか」という実現性や安全性に目が行きます。この視点や言葉のギャップを埋めないまま可否だけを議論すると、意図がすれ違い、検討が立ち消えになってしまうのです。
私たちのナレッジ基盤に関わる実務では、社内のデータや知識を横断的に検索・活用できる仕組みを構築し、それを各部署がツール開発に活かせるようにする構想が土台にあります。この構想を踏まえると、最初の受け渡しで必要なのは審査（可否判定）ではなく「翻訳」だと考えています。
現場の言葉をそのまま受け取るのではなく、「誰のどんな業務判断を、どんな知識で支えようとしているのか」という目的の言葉へ翻訳する。この置き換えができれば、開発側も「作ってほしい画面」ではなく「支えたい業務判断」を起点にして設計を始められるようになります。
私たちが返す短い方針書の六つの項目
現場から相談を受けたとき、私たちは「作れる／作れない」とすぐには答えず、短いMarkdown（テキスト記述言語）ファイル一枚で実装の方向性をまとめた「方針書」を返すアプローチを実践しています。
AIをAPIで組み込む開発では、コードを書く前に『実装計画』を文章化してから着手した方が成果に繋がりやすい、という発想と同じです。この方針書に含めるべき項目は次の6つです。
1. 目的
誰の、どのような業務上の判断や作業を軽くしたいのかを明確にします。
2. 利用する知識
参照・検索・更新の対象になるデータや知識領域を整理し、対象外も明記します。
3. 利用者と認可
誰が、どのデータに、どんな条件でアクセスできるかを定めます。これは、アクセス制御を設計する公的指針NIST SP 800-207 の考え方とも整合します。
4. API境界
アプリがどのAPI（システム間の接続窓口）を呼び、何を返し、何を保存するかを書きます。API連携ではデータごとの認可不備が大きなリスクになりうるという指摘OWASP API Security Top 10 2023 もあり、この点も見落とさないようにします。
5. 更新責任
知識や指示文、連携設定が古くなったとき、誰がいつ見直すかを決めておきます。
6. 未確定事項と再確認条件
何が未確定か、どんな変更が起きたら方針書を見直すべきかを明記します。
特に「3. 利用者と認可」と「4. API境界」は、後から追加しようとすると設計全体のやり直しが発生しやすい重要な部分です。どこまでのデータ領域を誰に参照させ、どの操作を許可するかを最初に一枚の紙で共有しておくだけで、途中の認識違いを未然に防ぐことができます。
これらの項目は、文脈と関係者を特定しリスクを継続管理する考え方NIST AI RMF 1.0 を小さな内製案件向けに翻訳したものだと捉えています。ただし、これらの指針がこの6項目の形式自体を定めているわけではなく、私たちが編集上の判断として組み立てた提案である点は明記しておきます。
速さを失わないために、方針書を仕様書にしすぎない
方針書は内製のスピード感を守る道具であり、承認を増やすための重い書類ではありません。仕様を固定せず使いながら改善していく開発スタイルでは、一度に扱える変更に限界があるという観察があります。
これは方針書についても同じことが言えると私たちは考えています。最初から完璧な仕様書を作ろうとすると、身動きが取れなくなります。だからこそ方針書は「開始許可のための書類」ではなく、「認可や利用知識、更新責任に関わる変更が起きたときに立ち返って見直す基準」として運用するのが適切です。
仕様を重厚にしすぎると更新自体が負担になり、現場のフィードバックを反映できなくなります。重要なのは詳細なUIを固定することではなく、権限やデータ境界などの根幹構造だけを握っておくことです。なお、方針書としての最適な文書量や見直しのタイミングについては、今後の運用の中で確かめていく必要がある問いだと認識しています。
実装開始後に見るべき指標と、残る設計課題
方針書が実際に役立っているかどうかは、感覚だけで判断せず記録できる形にしておきたいところです。有効と考えている観察指標は次の4点です。
- 最初の着手までの往復回数: 相談を受けてから最初の実装に着手するまでのコミュニケーション往復数
- 方針書項目の充足度: 返信した方針書の6項目がどれだけ埋まっていたか
- 要件の差し戻し件数: 実装開始後に生じた要件変更による差し戻しの回数
- 権限起因の手戻り件数: アクセス権限やセキュリティの認識違いによる手戻り件数
これは、入力や成功・失敗条件を明示しておくと後工程が結果を正しく使えるという、作業の約束事（ノード契約）に近い発想です。
また、現場へのAIプロダクト浸透には、トップダウンで組込む経路と、既存業務フローに自然に組込んでいく経路という二つの道筋があるという観察もあります。どちらの文化を持つ組織かによって、現場が方針書をどこまで自力で書けるようになるかという到達点も変わってくるはずです。これらは提案段階の観察であり、実測に基づく効果や成功率として述べているものではありません。
結論：内製を速くするのは、最初の翻訳を省かないこと
内製アプリの速度と安全性は、どちらか一方を選ばなければならない対立関係ではないと私たちは考えています。
目的、利用知識、権限、更新責任を一枚の短い方針書にまとめて返すこと自体が、両者をつなぐ実務上の単位になります。逆に権限設計を『後で考えよう』と後回しにするのは、素早く始めるための省略ではなく、手戻りを先送りしているだけの判断になりやすいというのが私たちの見方です。
次に現場から内製の相談を受けたときは、可否を答える前に、この6項目の方針書を一度返してみてください。そこから小さく、しかし安全に、実装を始めていくことができるはずです。
なお、ナレッジベースとツールを接続する設計についてはナレッジベースを全社の業務ツールへ接続する設計 を、現場でのAI定着アプローチについては現場でAIプロダクトを定着させるための考え方 もあわせてご参照ください。
