非エンジニアがAIアプリを組み立てられる社内基盤

社内の各部門がエンジニアの手を借りずにAIアプリを作り、その品質を確かめられるスタジオをLaravelとInertia、Reactで開発しました。利用者は対話形式でアプリの仕様を組み立て、社内ドライブから取り込んだ文書を、既製の検索・埋め込みサービスを組み合わせてAIの回答に反映させることができます（RAG と呼ばれる手法です）。取り込み元のアクセス権限はそのまま検索結果に引き継がれるため、閲覧できない文書がAIの回答に混ざることはありません。作成したアプリの応答は自動評価の仕組みで継続的に計測でき、LLMのプロバイダは複数から用途に応じて切り替え可能です。CloudFormationで環境ごとにインフラを定義し、運用手順も文書化しました。

権限を作り直さずに引き継ぐ

取り込み時に元の文書の閲覧権限を引き継ぎ、検索の段階で利用者ごとに結果を絞ります。AI基盤側で権限を独自に定義し直す方式は、社内ドライブ側で権限が変わるたびに二重管理のずれが生じ、そのずれが「見えないはずの文書がAIの回答に混ざる」という形で表面化します。既存の統制の外に新しい統制を作らない判断です。

評価がなければ基盤にしない

質問例と評価の観点を登録し、設定を変えるたびに自動で採点する仕組みを備えました。各部門が自由にアプリを作れる基盤では、作った本人以外に品質を判断できる人がいません。同じ基準で測れる仕組みが先にあることが、部門の工夫を組織の資産として扱える条件になります。

モデルが変わる前提で抽象化する

複数のLLMプロバイダを共通の層の裏で切り替えられるようにしました。提供の終了、値上げ、性能の変化はいずれも自社では制御できず、特定のモデルに合わせて作り込むほど乗り換えの費用が上がります。用途ごとに品質と費用の釣り合いを運用の中で調整できる余地を残しました。

作る人を現場に置く

アプリの仕様を対話で組み立てられるようにし、現場の担当者が自分の業務知識を直接反映できる形にしました。情報システム部門が要件を聞いて作る体制では、AIアプリの数だけ依頼が積み上がり、部門の待ち時間が活用の速度を決めてしまいます。ボトルネックの位置を移す設計です。

共通基盤に載せる範囲を限定する

文書の検索、評価、モデルの切り替えという、どの部門でも必要になる部分だけを基盤に持たせ、業務固有の処理は各アプリ側に残しました。共通化を広げるほど、一つの変更が全部門に影響します。基盤の境界を狭く保つことが、部門ごとの改修を独立させる条件です。

環境定義と運用手順の文書化

CloudFormationで環境ごとのインフラを定義し、運用の手順も文書として残しました。複数部門が使う基盤は、構築した担当者が異動した後も同じ環境を再現できなければ、更新が止まった時点で全部門の活用が止まります。担当者に依存しない状態を前提としました。

この種のシステムで検討する論点（想定例）

以下は同種の案件で一般的に検討する内容の整理であり、上記事例の詳細を示すものではありません。

監修: フィリット・コンサルティング株式会社公開 2026.09.13