AI 駆動開発基盤ご提案

AI 駆動開発基盤の
構築・移行のご提案

GitHub・Cloudflare を土台に、社内アプリの開発・デプロイ・権限管理を 1 つの基盤へ集約します。

2026 年 7 月　株式会社ソラグリ

※ GitHub、Cloudflare、Slack、Claude および各ロゴは各社の商標または登録商標です。本資料は提案を目的に各サービスへ言及・引用するもので、各社が本資料を後援・承認するものではありません。

ABOUT US

私たちについて — 株式会社ソラグリ

設立2025 年

代表取締役田村昂大

事業内容AI プロダクトの開発、および企業への AI 導入支援

CEO

田村昂大

東京大学工学部システム創成学科

生成 AI・衛星通信の企業でエンジニアとして従事。先端技術の社会実装を進める。

CTO

堀之内皓隆

東京大学工学部システム創成学科

newmo・UTEC 等でシステム開発に従事。幅広いエンジニアリングの知見で開発をリードする。

企業内での AI 導入・オンボーディング支援の様子

01ご提案

ご提案の全体像

開発者が書いたコードを GitHub に集約し、CI が Cloudflare 上の各システムへ自動デプロイ、結果を Slack に通知します。

personメンバー

GitHub

folder_openfika-platform

全アプリのコード・開発ルール・CI を 1 か所に集約

1 つのリポジトリ

CI 自動デプロイ

Cloudflareアプリ実行基盤

web_assetシステム 1

web_assetシステム 2

web_assetシステム 3

…

通知

Slackデプロイ・エラーをチャンネルに通知

02GitHub

1 つのリポジトリに集約する

全アプリを 1 リポジトリで管理し、ルール・Skill・CI を全員で共有する。

1 つのリポジトリ

fika-platform

folder_openapps/

├system-1/

└system-2/

extensionskills/

settings.github/

descriptionCLAUDE.md

ディレクトリごとにシステムを分けるアプリ 1 つ＝1 ディレクトリ。増えても同じ形で並ぶ

スキルは共有一度作った処理を、どのアプリからも呼び出せる

GitHub の使い方も統一自動チェックとデプロイの手順を全員で共通化

共通の開発ルールClaude が全員同じルールで実装する

personメンバー

…

全員で 1 つのリポジトリを共有する

03GitHub

main を守り、PR とレビューを必須にする

変更は branch → PR とし、CODEOWNERS の承認を経て main に反映、Cloudflare へ同期する。

close

admin_panel_settings担当者

レビュー・承認

check

person一般開発者

person開発者 A

person開発者 B

call_splitbranch-1

call_splitbranch-2

直接 push・直接コミット

PR

同期

lock

main

承認された PR
だけが反映

Cloudflare

各システムへ反映

groups

CODEOWNERS で、システムごとに承認できる担当者を決める。担当者が承認しない限り、その変更は main に入らない。

04Cloudflare

なぜ Cloudflare か

実行基盤は Cloudflare を推奨します。AI で運用でき、認証も安く一括で組めるのが理由です。

check_circleCloudflare のメリット

hub

インフラを 1 か所に集約できる

Workers・D1・Access を同じ場所で管理できる

smart_toy

AI が運用しやすい

UI 不要で、ファイルと CLI（wrangler）でいける

paid

安い（数十のアプリが $5 で動く）

Workers 有料プランは月 $5 から使える

verified_user

認証機能が優れている

Access で SSO とアクセス制御を追加できる

GCP

UI 操作が多く、AI が触りにくい
認証（IAM）のクセが強い

Vercel

認証が弱い
アプリが増えると料金が膨らみやすい

05セキュリティ

認証とアクセス制御の二段構え

入口の Cloudflare Access で社外を遮断し、システムごとに見られる人を絞る。

person社外・不正

personmember 1

personmember 2

@fika.tokyo 以外は拒否

Google 認証（@fika.tokyo）を通過

Cloudflare Access

shield_lockGoogle アカウントで認証

@fika.tokyoのみ許可

member1@fika.tokyo

member2@fika.tokyo

web_assetシステム1

badge人事システム

×

○

×

各システムで実装

gpp_good

社外・不正アクセスは確実に遮断入口で社内アカウント以外をすべて止める

manage_accounts

社内でも見せる人を限定できる人事など機密度の高いものは都度実装

※「member 1／member 2」は説明用の例です。実際は @会社ドメインの Google アカウントで認証します。

06デプロイ

CI で自動デプロイする

main にマージされると、CI（GitHub Actions）が自動で Cloudflare へデプロイし、結果を Slack に通知する。

ここから先は全自動

PR

check_circleapprove

main

bolt自動
実行

GitHub Actions デプロイ通知

Cloudflare各システムへ反映・公開

Slack「システム1 デプロイ完了」等を通知

デプロイ

成功

通知

sync

main が更新されるたびにサーバーが更新マージするだけで、対象システムが自動で最新になる

troubleshoot

失敗しても原因が分かりやすいデプロイ手順が型化されているので、切り分けが早い

07オプション

開発／本番の 2 台構成で安全に出す

重要なシステムは、開発サーバーで確認してから本番へ。本番反映は管理者の手動に限定する。

person開発者

GitHub main にマージ

dns

開発サーバーここで動作を確認する

public

本番サーバー確認後、管理者が公開する

開発

自動デプロイ

管理者が手動

1 開発して main にマージ

2 開発サーバーで動作確認

3 本番サーバーへ公開

verified_user

意図しない改修やバグが許されないシステム(顧客接点・経営数値など)には、この 2 段構成を推奨します。

08監視

エラーを検知して Slack に通知する

各システムのログを監視し、エラーを見つけたら Slack に自動で通知します。

Cloudflare

web_assetシステム 1

web_assetシステム 2

web_assetシステム 3

receipt_longログ

monitor_heart

エラー検知サーバー 異常を自動で見つける

エラー発見

通知

FIKA ワークスペース

#alerts

warning

FIKA AlertsAPP18:49

errorシステム2 でエラー

内容500: not key set

状態起動に失敗

※ Slack 名・ロゴは Slack Technologies の商標です。社内説明のための引用です。

09ご提案

移行の流れとお見積り

Step 1 から 7 の順に進めます。目安の期間・費用は各行に記載します。

1新しいリポジトリを作成

2Cloudflare アカウント作成・環境構築

3各種ファイル・CI などの設定

4岡本様の手元の開発環境を構築目安約 2 週間

5fika-sales など 1 アプリを移行30 万円（税別）

6他の社員へ展開し、相談に合わせてカスタマイズ1.5 万円/ 時（税別）

7モニタリング・継続運用

※ 記載の金額はすべて税別です。Cloudflare の実費（Workers 月 $5 程度・Access 50 ユーザー無料など）は別途、実質わずかです。