非エンジニアが自作アプリを社内にデプロイできる基盤を作った話

こんにちは、ハコベルでVPoTを務めている横山です。

ハコベルでは、エンジニア以外のメンバーに対しても生成AIツールの利用を推進しています。Claude Codeを配布したことで、非エンジニアでも自分の手元では業務改善ができるようになりました。一方で、作った仕組みをチームの他メンバーに展開するのが難しいという課題がありました。

そこで、非エンジニアでも自作アプリを社内限定URLにデプロイできる基盤を作りました。この記事では、その基盤を作るにあたって何を考え、どう組み立てたかを紹介します。

この記事の前提

次の環境で作った話です。自組織の構成に置き換えながら読んでいただければと思います。

• クラウド：Google Cloud（Cloud Run / Firestore / Cloud IAP / IAM）
• 認証基盤：Google Workspace
• 開発ツール：Claude Code（社内マーケットプレイスでプラグインを配布）

ざっくり言うと、Claude Code のスキルに「デプロイして」と頼むだけで、非エンジニアが作ったアプリを Google Workspace ログイン限定の URL に払い出せる基盤を、上のスタックで作った話です。

作るにあたって必要な考慮

この基盤に求めた条件は、大きく4つです。

• 利用ハードル：利用者はエンジニアではなく、GitHubアカウントも持っていません。CLIを叩くのも難しい。誰でも簡単にデプロイできる導線が要ります。
• セキュリティ：社外公開は絶対に避けなければいけません。社内限定を、運用ルールではなく構成そのもので機械的に担保したい。加えて「社内でも特定のメンバーにだけ見せたい」という要望もありますが、認証・認可を個別に実装するのは非エンジニアには無理です。ここも構成側で担保します。
• コスト：すべてのアプリを常時稼働させると、使われていないアプリの分までお金がかかります。アクセスがないときは自動で停止したい。
• ガバナンス：誰が何をデプロイしているかを把握でき、使われなくなったアプリを棚卸しできる状態にしたい。

利用ハードルを下げつつセキュリティを担保し、コストを抑えながらガバナンスも効かせる。この4つを同時に満たすことを目指して作りました。

仕組みの概要

基盤は、大きく3つの部品でできています。

1. Claude Code のスキル：非エンジニアの窓口です。中身はデプロイ用のCLIを呼び出すだけで、難しい判断はデプロイAPIに任せます。
2. デプロイAPI：サーバ側の司令塔です。アップロードされたアプリの中身を検証し、ビルドしてCloud Runにデプロイします。何を許して何を弾くかの判断は、すべてここが持ちます。
3. データ保存の社内SDK：アプリがデータを保存するための社内ライブラリです。アプリごとに割り当てたデータベースへ、決められた作法でしか書き込めないようにしてあります。

利用者が直接触るのは Claude Code のスキルだけで、あとは対話形式でデプロイできる構成にしました。

デプロイの流れ

ハコベルでは社内のマーケットプレイスにプラグインを載せていて、インストールするだけでスキルを取り込めます。あとは、作ったアプリのフォルダで次のように指示するだけです。

このアプリを社内環境にデプロイして

あとはスキルが対話形式で、アプリ名・公開範囲・保存の要否などを順に聞き、確認のうえでデプロイまで進めてくれます。

デプロイの可否は、Google Workspace へのログインと、特定の Google グループへの所属で判定しています。社内であってもデプロイできる人を絞ることで、ガバナンスを担保します。一方で、それ以外の Google Cloud や GitHub へのログインは一切不要にしました。非エンジニアにこれらのアカウントを発行してもらうのはハードルが高いからです。

アクセス制御の仕組み

セキュリティの方針を満たすために、「公開してはいけない」ではなく「そもそも公開する選択肢が存在しない」構成にしています。デプロイされたアプリへのアクセスは、次の3つのゲートを順に通ります。

① 入口を1箇所に強制する

デプロイされたアプリへのアクセスは、まずGCPのIAP（Identity-Aware Proxy）を通ります。IAPは、ハコベルのGoogle Workspaceにログインしている人でなければ中に入れません。社外の人はアプリの画面にすら到達できない、というのが構成上の前提です。各アプリに個別のログインを実装させると実装ミスがそのまま穴になるので、認証は入口の1箇所に集約しました。

② 認可をアプリの外で強制する

次に、アプリごとの認可です。非エンジニアがAIでアプリを作るという性質上、アプリケーションのコードで認証・認可を正しく担保するのは困難です。そこで、アプリ側には認可の判定を一切行わせない設計にしました。

各アプリは2つのコンテナで構成されていて、前段に基盤側が用意するゲートプロキシを立て、利用者のアプリはその後ろで動きます。プロキシにはあらかじめ認可の処理が実装してあり、公開範囲（オーナーのみ／特定グループ／全社）は設定値として渡されます。こうすることで、非エンジニアはコードを書かずに公開範囲を切り替えられます。仮にアプリのコードに脆弱性があっても、プロキシを通らずに外から直接アプリを叩く経路がないので、被害はそのアプリの中に閉じ込められます。

③ データをアプリごとに分離する

また、アプリごとにデータストアを完全に分離しています。アプリはデータアクセス用のSDK経由でしかデータを保存できず、アプリごとに独立したデータベースが割り当てられ、そのアプリは自分のデータベースにしか触れないことをGCPのIAMで保証しています。SDKには接続先のデータベースを選ぶ引数がそもそも無いので、利用者が別のアプリのデータを指定しようとしても、コードの書きようがありません。

コスト

社内ツールの多くは、四六時中アクセスされるわけではありません。そこで、使われていない時間はお金がかからないようにしています。

• 最小インスタンス0。すべてのアプリはCloud Runの min-instances=0（scale-to-zero）で動きます。アクセスが途切れればインスタンスは消え、その間は課金されません。基盤側のデプロイAPIなどのサービスも同じく min=0 で、デプロイ要求が来たときだけ起動します。
• データベースも使った分だけ。データの保存にはFirestoreを使っています。サーバを常時立てる方式ではなく、保存量と読み書きの回数に応じた課金なので、アクセスのないアプリのデータベースが固定費を生むことはありません。

アプリ、デプロイAPIどちらも常駐サービスにせず、必要なときだけ起動することでコストを最小化しています。

管理ダッシュボード

誰がどんなアプリをデプロイしているのか、使われなくなったアプリが残っていないかを一元管理できるダッシュボードを用意しています。これも社内限定で、IAPに加えて管理者グループの所属チェックで保護し、管理者だけが開けます。この管理画面では以下の確認・操作を行えます。

• 全社のアプリ一覧（アプリ名・オーナー・状態・公開範囲）
• 画面からのアプリ削除・公開範囲の変更

社内管理者がこのダッシュボードから、いま社内でどんなアプリが動いているかを横断的に把握できます。使われなくなったアプリを見つけて削除できるので、誰が何を動かしているか分からない状態や、誰も使っていない野良アプリの放置を防げます。

まとめ

非エンジニアが自作アプリを社内にデプロイできる基盤について、考えたことと仕組みを紹介しました。

• 認証・認可をアプリに持たせず基盤側の仕組みに寄せることで、安全性を機械的に担保した
• scale-to-zero なサービスを選ぶことで、コストを最小限に抑えた
• アプリを一元管理できるダッシュボードを用意し、ガバナンス面もカバーした

生成AIで作った社内アプリを、個人の手元からチームの仕組みへ広げていく際の参考になれば幸いです。