JA
RAILSHOT.
展示室へ戻る

Railshot

AI deployment & operations platform

ローカルで作ったWebアプリを、用意されたクラウドとオンプレミス環境にデプロイし、運用します。

ローカルで作ったWebアプリを、用意されたクラウドやオンプレミス環境にデプロイし、運用まで続けるAIデプロイ・運用プラットフォームです。

2026.09.28 — 2026.10.04 · 終了

チームプロジェクト · 担当：CIの企画・実装、CSPクラスターとAnsibleインターフェース、運用、チームのコードレビューと統合

SoftBank Hackathon 2026 powered by KOREC & Progate予選参加 · 本選進出の発表は2026年10月26日予定（2026年10月7日時点）

  • Web実装済み · ハッカソン
  • MCPサーバー実装済み · リモート · ローカル

Web画面と自分のエージェントが、同じ製品APIでデプロイを要求します。

受け付けたデプロイ要求が、CIの検査とイメージの公開を経て、登録された対象でのGit構成とArgo CDによる適用、公開HTTPSの確認まで進む製品の構成です。適用されたrevisionと公開確認の両方がそろったときだけ成功として記録し、知りえない結果はunknownのまま残します。

Web画面、またはMCPで接続した自分のAIエージェントからプロジェクトを提出すると、デプロイファイルの準備、失敗の修正、イメージの公開、環境への適用、公開URLの確認まで進みます。デプロイ後も同じ画面で履歴とログを確認し、更新、停止、再開、削除を管理します。チームプロジェクトです。

大会開発期間 September 28, 2026 to October 4, 2026

ハッカソン期間に作ったWeb画面とMCPサーバーです。リモートMCPはOAuthでログインして提出し、ローカルのフォルダーはローカルMCPで提出します。

製品構成図 · 公開コミット645e28aのコードパスから作図
Railshot製品構成図Railshot製品の構成要素と接続です。Web画面、リモートのOAuth MCP、ユーザーのコンピューター上のローカルMCPが同じ製品APIでデプロイを要求し、APIはソースコミットとCI実行を登録します。CIは固定された検査で判定し、検査済みのイメージをGHCRに公開します。CDアダプターは、登録された対象が公開記録と一致する場合にのみconfig GitとArgo CDで適用し、登録された公開HTTPSアドレスを確認して結果を記録します。メトリクスは判定とは別の観測です。ブラウザユーザーフォルダー · ZIP · GitHub URLMCPクライアントChatGPT · Codex · Clauderailshot-local MCPユーザーのコンピューター · stdioGHCRダイジェスト指定のイメージAI SDK providerCodex · Claude SDKconfig Gitリポジトリ登録済みのworkload.json公開HTTPS URL登録済みのhealthパスPrometheus運用のcontrol VM · 読み取りapps/dashboardWeb画面 · 履歴 · Insightsagent/remote-mcp.jsOAuth MCP · deploy_repositoryapps/api検証 · 対象確認 · 202受付デプロイキュー · 同時3件CI実行のバインド · 観測cd.js · deployPublishedmetrics observerapi/product-store.jsoperationの状態 · runのバインドgitops/bridge.py信頼済みconfig · 登録済みの対象commit · push · リモートの読み戻しArgo sync · 観測公開HTTPSプローブArgo CDApplication · AppProject検査apps/<tenant>/<app>ソースコミット · trailerrailshot-deploy.ymlループ · ベースライン検査L0–L3SDKによる修正 · 修正可能な失敗のみ同じ検査 → 検査済みのbundleリリース · GHCRへ公開 · バインドK3sアプリクラスターworkload · ServiceRailshotプラットフォーム運用クラスター · AWSGitHub非公開のappsリポジトリ · Actions登録済みの対象プロバイダーごとの公開経路1 フォルダー · ZIP · GitHub URL · ブラウザユーザー → Web画面 · 履歴 · Insights12同じ製品API · /api/v13 OAuth · deploy_repository · MCPクライアント → OAuth MCP · deploy_repository34同じ製品API5 ZIPアップロード · deploy_local_project · railshot-local MCP → 検証 · 対象確認 · 202受付56 queuedとして記録 · 202 · 検証 · 対象確認 · 202受付 → operationの状態 · runのバインド67 キューの順序 · operationの状態 · runのバインド → デプロイキュー · 同時3件78デプロイ状態 · 履歴1source commit2workflow_dispatch3提出コミット4修正案の要求 · 条件付き5検査済みイメージを公開6実行 · 公開記録の読み取り7 failed · publication_unverified · CI実行のバインド · 観測 → operationの状態 · runのバインド71images.json · spec · verdict · manifest2適用 · 登録済みの対象3workload commit · push4revision5sync · 観測6適用7イメージpull · ダイジェスト8HTTPS health9 公開経路 · 公開HTTPS URL → workload · Service910 succeeded · revision · URL · cd.js · deployPublished → operationの状態 · runのバインド1011 unknown · 再調整が必要 · cd.js · deployPublished → operationの状態 · runのバインド111PromQLクエリ2scrape · probe3デプロイ状態 · 履歴4HTTPS health

提出 → 受付

Web画面、リモートMCP、ローカルMCPが同じ製品APIを呼び出し、APIは確認したリクエストをqueuedとして記録して202で応答します。

  1. ブラウザユーザーフォルダー · ZIP · GitHub URLWeb画面 · 履歴 · Insightsapps/dashboard

    Web画面でソースと登録済みの環境を選びます。

  2. Web画面 · 履歴 · Insightsapps/dashboard同じ製品API · /api/v1検証 · 対象確認 · 202受付apps/api

    Web画面は同一オリジンの製品APIを呼び出します。

  3. MCPクライアントOAuth · deploy_repositoryOAuth MCP · deploy_repositoryagent/remote-mcp.js

    リモートMCPはOAuthで接続し、公開GitHubリポジトリを入力として受け取ります。

  4. OAuth MCP · deploy_repositoryagent/remote-mcp.js同じ製品API検証 · 対象確認 · 202受付apps/api

    リモートMCPサーバーは、内部のAPIクライアントで同じデプロイAPIを呼び出します。

  5. railshot-local MCPZIPアップロード · deploy_local_project検証 · 対象確認 · 202受付apps/api

    ユーザーのコンピューター上のstdio MCPがフォルダーをZIPにまとめてアップロードします。このセッションはリモートのOAuthセッションとは共有されません。

  6. 検証 · 対象確認 · 202受付apps/apiqueuedとして記録 · 202operationの状態 · runのバインドapi/product-store.js

    入力、登録済みの対象、容量、idempotencyキーを確認し、operationをqueuedとして記録して202で応答します。202は受付であり、デプロイの成功ではありません。

  7. operationの状態 · runのバインドapi/product-store.jsキューの順序デプロイキュー · 同時3件apps/api

    同時デプロイ数（既定3）の範囲で、受付順に取り出します。

  8. operationの状態 · runのバインドapi/product-store.jsデプロイ状態 · 履歴Web画面 · 履歴 · Insightsapps/dashboard

    Web画面とMCPツールは同じoperation記録を読み取ります。最新の試行と現在の検証済みデプロイを分けて表示し、AIタスクの完了はデプロイの成功ではありません。

CI検査 → イメージ公開

固定されたプラットフォームコードが提出コミットを検査し、修正可能な失敗だけをAIに任せ、同じ検査を再び通過したイメージだけを公開します。

  1. デプロイキュー · 同時3件apps/apisource commitソースコミット · trailerapps/<tenant>/<app>

    提出されたソースを非公開のappsリポジトリのコミットにし（Railshot-RequestとRailshot-Targetのtrailer付き）、ブランチをforceなしで更新します。

  2. デプロイキュー · 同時3件apps/apiworkflow_dispatchループ · ベースライン検査L0–L3railshot-deploy.yml

    tenant、app、source_commit、target_idで実行を要求します。応答が失われても再送せず、同じコミットの実行を検索します。

  3. ソースコミット · trailerapps/<tenant>/<app>提出コミットループ · ベースライン検査L0–L3railshot-deploy.yml

    提出コミットと固定されたプラットフォームコード（PLATFORM_REF）だけをcheckoutします。

  4. SDKによる修正 · 修正可能な失敗のみrailshot-deploy.yml修正案の要求 · 条件付きAI SDK provider

    修正可能な失敗分類のときだけ呼び出し、同じ失敗が繰り返されるか試行上限に達すると停止します。合否はLLMではなく検査が決めます。

  5. リリース · GHCRへ公開 · バインドrailshot-deploy.yml検査済みイメージを公開GHCR

    検査を通過したbundleを確認した後、同じイメージをGHCRに公開します。再ビルドはしません。

  6. CI実行のバインド · 観測apps/api実行 · 公開記録の読み取りrailshot-deploy.yml

    run id、ソースコミット、対象、appが受付記録と一致した場合にのみ、公開として認めます。

  7. CI実行のバインド · 観測apps/apifailed · publication_unverifiedoperationの状態 · runのバインドapi/product-store.js

    CIの失敗や未確認の公開は診断とともに記録し、CDには渡しません。

適用 → 公開確認

公開記録が登録済みの対象と一致する場合にのみconfig GitとArgo CDで適用し、登録された公開HTTPSアドレスの確認が通ってはじめて成功として記録します。

  1. リリース · GHCRへ公開 · バインドrailshot-deploy.ymlimages.json · spec · verdict · manifestcd.js · deployPublishedapps/api

    CDは公開記録のファイルを信頼済みのローダーで読み込みます。CI自体は、クラスターのリソースもURLもデプロイの成功も生み出しません。

  2. cd.js · deployPublishedapps/api適用 · 登録済みの対象信頼済みconfig · 登録済みの対象gitops/bridge.py

    登録済みのアプリとtenantが公開記録と一致する場合にのみ、信頼済みのconfigでgitops/bridge.pyを実行します。

  3. commit · push · リモートの読み戻しgitops/bridge.pyworkload commit · pushconfig Gitリポジトリ

    専用ブランチの登録済みパスにあるworkload.jsonだけをコミットし、push意図を先に記録してからpushし、リモートのrevisionを読み戻します。結果が不確かなpushは繰り返しません。

  4. config GitリポジトリrevisionApplication · AppProject検査Argo CD

    Argo CD Applicationが指すconfigリポジトリのrevisionです。

  5. Argo sync · 観測gitops/bridge.pysync · 観測Application · AppProject検査Argo CD

    AppProjectを検査した後にsyncを要求します。観測時はsyncせず、読み取るだけです。

  6. Application · AppProject検査Argo CD適用workload · ServiceK3sアプリクラスター

    登録された対象クラスターにworkloadを適用します。

  7. workload · ServiceK3sアプリクラスターイメージpull · ダイジェストGHCR

    公開されたダイジェストをpullします。非公開のGHCRには専用のpull用認証情報が必要です。

  8. 公開HTTPSプローブgitops/bridge.pyHTTPS health公開HTTPS URL

    運用者が登録したHTTPSのhealthアドレスだけを、リダイレクトなしで、200（設定されていれば期待するJSONも）を返すか確認します。

  9. 公開HTTPS URL公開経路workload · ServiceK3sアプリクラスター

    公開経路（LB、NodePort、証明書）は、プロバイダーと登録済みの対象ごとに異なります。

  10. cd.js · deployPublishedapps/apisucceeded · revision · URLoperationの状態 · runのバインドapi/product-store.js

    cd.deployed、revision、成功した公開HTTPS確認とその時刻、有効なURLがそろったときだけsucceededとして記録します。

  11. cd.js · deployPublishedapps/apiunknown · 再調整が必要operationの状態 · runのバインドapi/product-store.js

    知りえない結果はunknownのまま残し、同じ適用を再送も巻き戻しもしません。

観測 · 判定とは別

メトリクスとプローブはデプロイの成功を決めません。欠損、古い値、失敗した値はそのまま表示します。

  1. metrics observerapps/apiPromQLクエリPrometheus

    up、probe_success、Podの系列を読み取ります。欠損、古い値、失敗した値はその状態のまま表示し、0に置き換えることはありません。

  2. Prometheusscrape · probeworkload · ServiceK3sアプリクラスター

    exporterのscrapeとHTTPプローブです。これらのメトリクスはデプロイ成功の判定には使いません。

  3. operationの状態 · runのバインドapi/product-store.jsデプロイ状態 · 履歴Web画面 · 履歴 · Insightsapps/dashboard

    Web画面とMCPツールは同じoperation記録を読み取ります。最新の試行と現在の検証済みデプロイを分けて表示し、AIタスクの完了はデプロイの成功ではありません。

  4. 公開HTTPSプローブgitops/bridge.pyHTTPS health公開HTTPS URL

    運用者が登録したHTTPSのhealthアドレスだけを、リダイレクトなしで、200（設定されていれば期待するJSONも）を返すか確認します。

すべての接続を同じ太さで表示します。フローを選ぶと、その経路だけを番号付きで強調します。

  • 実線 · ソース、イメージ、リクエストが流れる方向
  • 破線 · 実行要求、適用、sync
  • 長い一点鎖線 · 状態の読み取り、プローブ、メトリクス、判定とは別
  • 短い破線 · 記録された失敗または不明な結果
  • 太い黒線 · 選んだフロー。番号は順序
  • ボックス · 所有の境界、見出しにソースパス
  • 内側のチップ · その境界内の構成要素
  • 破線ボックス · プラットフォーム外
  • オレンジの枠 · モデルが判断する場所
  • 製品API
  • デプロイ記録
  • CD実行境界
  • 入口 · CI · 対象

docs/architecture/README.mdにある10月2日時点（bc61a5a）の図は実装の履歴で、この構成図は645e28aのコードに従います。プロバイダーとネットワーク経路は登録済みの対象ごとに異なり、すべてのプロバイダーが常に稼働しているという意味ではありません。