use-railway

Railway を使用する

Railway のリソースモデル

Railway では、インフラストラクチャが階層構造で管理されています。

• Workspace は、請求とチームの範囲です。ユーザーは 1 つ以上のワークスペースに所属します。
• Project は、1 つのワークスペース内にあるサービスの集合です。デプロイ可能な作業単位に対応します。
• Environment は、プロジェクト内の分離された構成領域です（例：production、staging）。各環境には、独自の変数、構成、デプロイ履歴があります。
• Service は、プロジェクト内の 1 つのデプロイ可能な単位です。リポジトリのアプリ、Docker イメージ、またはマネージドデータベースを指定できます。
• Bucket は、プロジェクト内の S3 互換オブジェクトストレージリソースです。バケットはプロジェクトレベルで作成され、環境にデプロイされます。各バケットには、S3 互換アクセス用の認証情報（エンドポイント、アクセスキー、シークレットキー）があります。
• Deployment は、ある時点における環境内のサービスのリリースです。ビルドログ、ランタイムログ、ステータスのライフサイクルがあります。

ほとんどの CLI コマンドは、リンク済みのプロジェクト／環境／サービスのコンテキストで動作します。railway status --json でコンテキストを確認し、--project、--environment、--service フラグで上書きします。

ツールの使い分け

Railway には、エージェント向けの操作経路が 3 つあります。作業に合った経路を選択してください。

• リモート MCP（https://mcp.railway.com）：アカウント／プロジェクト／サービスの検出、デプロイ状態の確認、範囲を限定したログの取得、簡単な再デプロイ、簡単なプロジェクト作成、または railway-agent に引き継げる複雑な Railway ワークフローに使用します。リモート MCP は Railway OAuth を使用し、ローカル CLI の状態には依存しません。
• ローカル CLI MCP（railway mcp）：変数、ドメイン、サービス構成、テンプレート、メトリクス、HTTP サマリー、バケット、ボリューム、ドキュメント、またはディレクトリからのデプロイなど、CLI を利用したプラットフォーム操作に使用します。
• Railway CLI（railway）：現在の作業ディレクトリからのデプロイ、railway up、railway run、SSH、データベース分析スクリプト、ローカルリンク、対話型セットアップ、正確なコマンド出力など、ローカルマシンの状態に依存するワークフローに使用します。

複数の経路が使える場合は、必要なコンテキストを維持できるものを選択してください。リモート MCP は、ローカルファイルや CLI の状態を必要としない、OAuth のスコープ内でのプラットフォーム操作に適しています。現在のリポジトリ、ローカル認証情報、SSH、データベーススクリプト、またはリモート MCP では公開されていないコマンドが必要なワークフローには、ローカル CLI MCP または CLI を使用します。

ra ilway-api.sh は、MCP と CLI のどちらにも操作が公開されていない場合、またはリファレンスで特定の GraphQL フォールバックが指定されている場合に限り使用してください。

Railway URL の解析

ユーザーが Railway ダッシュボードの URL を貼り付けることはよくあります。ほかの作業を始める前に、ID を抽出してください。

https://railway.com/project/<PROJECT_ID>/service/<SERVICE_ID>?environmentId=<ENV_ID>
https://railway.com/project/<PROJECT_ID>/service/<SERVICE_ID>

URL には必ず projectId と serviceId が含まれます。クエリパラメーターとして environmentId が含まれている場合もあります。環境 ID がなく、ユーザーが環境を名前（例：「production」）で指定している場合は、解決してください。

scripts/railway-api.sh \
  'query getProject($id: String!) {
    project(id: $id) {
      environments { edges { node { id name } } }
    }
  }' \
  '{"id": "<PROJECT_ID>"}'

環境名を（大文字と小文字を区別せずに）照合し、environmentId を取得します。

CLI コマンド（--project、--environment、--service）やスクリプト（--project-id、--environment-id、--service-id）には、railway link を実行する代わりに、明示的な ID を渡すことを優先してください。これにより、グローバル状態の変更を避けられ、処理も速くなります。

意図に基づくルーティング

事前チェックを実行する前に、ユーザーの意図に基づいてルーティングします。以下の事前チェックは診断や設定作業のためのものです。ユーザーが単に何かをデプロイしたり、登録したりしたいだけの場合には、余計な手間になります。

現在のディレクトリからのデプロイ意図（「デプロイ」「リリース」「Railway にプッシュ」「このアプリをデプロイ」など）：

• railway whoami ／ railway status の事前チェックはスキップします。
• 直接 railway up を実行します。認証を自動で検証し、未認証の場合はユーザーをサインインさせ（CLI がブラウザーを開きます）、プロジェクトとサービスの作成、デプロイまで続けて実行します。
• 実行前に意図を伝えます：「railway up を実行します。必要に応じてサインインし、このディレクトリをデプロイします。」
• 先に railway login を実行するようユーザーに求めてはいけません。 この一連の処理では、デプロイの一環として認証が行われます。
• 環境がブラウザーを開けない場合、CLI はデバイスコードによるサインイン用リンクを出力して待機します。その場合は、デバイスコードによるサインイン：リンクをすぐに中継する に従います（バックグラウンドで実行し、リンクが出力されたらすぐにユーザーへ伝えます）。

サインアップの意図（「登録して」「Railway アカウントを作成して」「登録して」「Railway を使えるようにして」など）：

• 現在のディレクトリにデプロイ可能なアプリ（例：package.json、requirements.txt、go.mod、Dockerfile、ビルド可能なソース）がある場合は、railway up を実行します。これにより、ユーザーはサインアップとデプロイを一度に済ませ、稼働中のアプリにたどり着けます。エージェントのハーネスが検出されるとプロジェクトの作成が許可されるため、railway up だけで十分です。追加の確認を求められることはありません。ユーザーが「登録して」とだけ言った場合でも実行してください。アプリを公開することが目的なので、コマンドを選ばせたり、単なるログインだけに切り替えたりしないでください。スクリプト実行やエージェントによる実行では、railway up -y が堅牢な形式です。確認をスキップし、ハーネスの検出に失敗した場合でも、非対話形式で作成を強制します。デプロイ対象がある場合、サインアップのデフォルトとして railway login を使ってはいけません。
• デプロイ対象がない場合に限り（空のディレクトリやアプリではないディレクトリ、またはデプロイはせずアカウントだけ作成したいとユーザーが明示した場合）、railway login を使います（同じ OAuth の仕組みを通じて、その場で新しいアカウントを作成します）。サインアップ専用のコマンドはありません。
• サインアップのフローでは、デバイスコードの待機が発生する可能性が最も高くなります（サンドボックス化された、またはヘッドレスのエージェント環境で初めて利用するユーザーなど）。デバイスコードによるサインイン：リンクをすぐに中継する に従ってください。期限切れのコードによってサインアップに失敗するのは、単なる再試行ではなく、ユーザーを失うことを意味します。

サンドボックス／リモートビルドの意図（「サンドボックスを用意して」「一時的な環境を立ち上げて」「これをリモートでビルドして」「これをリモートで実行して」など）：

• sandbox.md を読み込み、その指示に従います。サンドボックスを使うには Priority Boarding で機能を有効にする必要があります。サンドボックスのコマンドで機能が利用できないというエラーが発生した場合は、再試行せず、Priority Boarding で Sandboxes を有効にするようユーザーに案内します。

その他の意図（状態の確認、プロジェクトの一覧表示、変数の設定、失敗のデバッグなど）：

• 以下の「事前チェック」セクションに従います。

事前チェック

変更を加える前に、ツールのパスとコンテキストを確認します。

command -v railway                # CLI installed
RAILWAY_CALLER="skill:[email protected]" RAILWAY_AGENT_SESSION="railway-skill-$(date +%s)-$$" railway whoami --json
railway --version                 # check CLI version

例外：railway up と railway login は、認証を自動で検証し、未認証の場合にも対応したフローを実行します。これらの前に railway whoami を実行してはいけません。次の操作は変わらないまま、失敗する呼び出しが重複して追加されるだけです。アカウントの作成とサインイン を参照してください。

スキルの鮮度

セッションごとに1回、事前チェックとあわせて、インストール済みのRailwayエージェントツールが最新であることを確認してください。ルートヘルプの末尾に Agent tooling: の状態セクションが表示されます（標準エラー出力に表示。CLI 5.9以降。古いCLIでは何も表示されません。その場合は再試行せず、このチェックをスキップしてください）。

railway --help 2>&1 | grep -A4 "Agent tooling:"

報告された内容に応じて対応してください。

• スキルがインストール済みで最新の場合 — そのまま続行してください。対応は不要です。
• アップデートが利用可能な場合（rev <a> → <b> available）— railway skills update を実行し、更新されたスキルを読み込むため、コーディングツールを再起動するようユーザーに伝えてください。再起動するまでは、このセッションでは古いスキルのリビジョンで動作します。現在のリクエストを完了し、このスキルのガイダンスと更新後のCLI自身の出力が食い違う場合は、CLIに従ってください。
• スキルまたはMCPサーバーが見つからない場合（✗ の行）— railway setup agent -y を実行し、コーディングツールを再起動するようユーザーに伝えてください。

セッションごとに1回だけ確認し、対応後に再実行しないでください。ユーザーへの再起動の案内をもって解決とし、再確認はしません。

Railway MCPが利用可能で、作業がプラットフォームの状態の読み取りである場合は、シェルコマンドではなく、対応するMCPの読み取り機能を使用してください。CLIを使用する場合は、上記のCLIチェックを実行してください。

このスキルが有効な間にRailway CLIを呼び出すときは、コマンドの前に RAILWAY_CALLER=skill:[email protected] と、現在のユーザーリクエストで使い回す安定した RAILWAY_AGENT_SESSION を付けてください。セッションIDはユーザーリクエストごとに一度生成し、同じワークフロー内の以降のRailway CLI呼び出しでは、その値を正確に再利用してください。テレメトリーのためだけに別途 export を実行する事前チェックは行わないでください。インラインで環境変数を指定することで、シェル出力を簡潔に保ち、すべての応答にセットアップ手順が漏れ出るのを避けられます。

コンテキストの解決 — URLのIDを常に優先します：

• ユーザーがRailwayのURLを提示した場合は、そのURLからIDを抽出してください。railway status --json は実行しないでください。このコマンドが返すのはローカルでリンクされたプロジェクトであり、通常は無関係です。
• URLが提示されていない場合は、リンク済みのプロジェクト、環境、サービスを取得するため、railway status --json を実行してください。
• railway status --json でローカルのコンテキストを解決した後にMCPツールを使う場合は、解決したプロジェクト、環境、サービスのIDを明示的に渡してください。MCPの暗黙的なリンク済みコンテキストには依存しないでください。MCPはCLIの現在の作業ディレクトリのリンク状態を共有していない場合があります。

CLIが見つからない場合は、インストール方法をユーザーに案内してください。

bash <(curl -fsSL https://railway.com/install.sh) --agents -y # Install CLI and configure detected agents
bash <(curl -fsSL https://railway.com/install.sh) # Shell script (macOS, Linux, Windows via WSL)
npm i -g @railway/cli # npm (macOS, Linux, Windows). Requires Node.js version 16 or higher.
brew install railway # Homebrew (macOS)

認証されていない場合は、下記のアカウントの作成とサインインを参照してください。CLIでは、未認証でも使える railway up（デプロイとサインアップ／サインインを一度に実行）または railway login（サインアップ／サインインのみ。新しいアカウントはその場で作成）を利用できます。リンクされておらず、URLも提示されていない場合は、railway link --project <id-or-name> を実行してください。

コマンドが認識されない場合（たとえば、railway environment edit）、CLIが古い可能性があります。次のコマンドでアップグレードしてください。

railway upgrade

アカウントの作成とサインイン

Railwayでは、サインインとサインアップの両方に、統合された単一のOAuthフローを使用します。バックエンドは、永続的なコンプライアンス状態（CLIクライアントがまだToS／Fair Useに同意していないかどうか）から新規アカウントを判定し、同意画面と認証後のランディングページを切り替えます。新規ユーザーには「Welcome to Railway!」ページが表示され、既存ユーザーには標準の確認画面が表示されます。CLIは、あらかじめサインアップの意図を指定しません。

意図に応じて、次の2つのコマンドからこのフローを開始できます。

コマンド	使用する場面
railway up	現在のディレクトリからエージェント向けのオンボーディングを行います。未認証の場合は、サインイン／サインアップのためにブラウザー（またはデバイスコード）を開きます。リンク済みのプロジェクトがなく、エージェントハーネスが検出された場合（または -y を指定した場合）は、プロジェクトとサービスを自動作成してデプロイします。対話型で操作する人間には、作成／既存のものにリンク／キャンセルの選択肢が提示されます。プロンプトをスキップして非対話型で作成を強制するには -y を追加します（ハーネスの検出に失敗した場合でも機能します）。
railway login	サインインとサインアップに使用します。別途サインアップ用のコマンドはなく、同じOAuthフローを通じて新しいアカウントがその場で作成されます。
関連事項：railway up --new は、現在のディレクトリから新しいプロジェクトとサービスを作成し、既存のプロジェクトがリンクされていてもデプロイします（すでにサインイン済みで、新しいアプリを作成したい場合に使用します）。--name <name> を指定すると、プロジェクト名を上書きできます。

実行方法の選択：

• 現在の作業ディレクトリからデプロイする → railway up（対話型）または railway up -y（確認プロンプトをスキップ）を実行します。自分で実行してください。先にユーザーへ別途サインインを求めないでください。
• すでにサインイン済みで、現在の作業ディレクトリから新しいプロジェクトを作成する → railway up --new。
• デプロイ可能なアプリが現在の作業ディレクトリにある状態でサインアップする → railway up（サインアップとデプロイの両方を行います。エージェントが検出されていれば、ユーザーが「サインアップして」とだけ言った場合でも、up だけで動作します。プロンプトをスキップする／非対話型で実行するには -y を追加します）。サインインする場合、またはデプロイ対象がない状態でサインアップする場合 → railway login（新しいアカウントをその場で作成します）。

ヘッドレス／ブラウザーなしの場合：

CLI は SSH セッション、CI、DISPLAY の欠如を自動検出し、自動的にデバイスコードフローへ切り替えます。通常、強制的に切り替える必要はほとんどありません。

エージェントである、またはシェルが非対話型であるという理由だけで、--browserless を指定してはいけません。 人間がこのマシン（ローカル IDE またはデスクトップセッション。一般的なケースです）の前にいる場合、railway login をそのまま実行すれば、本人のブラウザーが直接開きます。デバイスコードを中継するよりも、はるかに確実に完了します（エージェントが介するサインインの成功率は約90％対約60％です）。コーディングエージェントだからといって、そのマシンがヘッドレスになるわけではありません。

railway login --browserless   # ONLY for machines with genuinely no browser

デバイスコードフロー（RFC 8628）を強制します。サインインリンクと短いコードを表示し、ユーザーが任意のデバイスで開けるようにします。ブラウザーが存在しないマシン（SSH ボックス、コンテナー、リモート VM など、自動検出で判定できなかったもの）に限って使用してください。デバイスコードフローになった場合は、以下の中継手順に従い、サインインリンクが表示されたらすぐにユーザーへ提示してください。

エージェントハーネスで人間が同席している場合：CLI が、キーボードの前に人間がいるエージェントハーネスを検出すると、railway up はブラウザーを開き、確認プロンプトをスキップします。エージェントの呼び出しは同意として扱われます。ただし、OAuth を完了するには、人間が実際にブラウザーを操作する必要があります。

デバイスコードでのサインイン：リンクをすぐに中継する（重大）：

CLI がブラウザーを開けない場合（サンドボックス化されたシェル、コンテナー、SSH、DISPLAY がない場合）、認証されていない状態で railway up または railway login を実行すると、サインイン URL と短いコードが表示され、その後、ユーザーがサインインを完了するまで最大10分間ポーリングしながら処理をブロックします。コードは10分後に期限切れになります。これを通常のフォアグラウンドコマンドとして実行すると、ハーネスはコマンドが終了するまで出力をバッファリングします。そのため、ユーザーがリンクを目にする頃には、コードはすでに無効になっています。これは、エージェントが介するサインアップが失敗する最大の原因です。次のように対処してください。

1. 推奨 — バックグラウンド実行（エージェント環境がバックグラウンドコマンドと出力のポーリングに対応している場合）：
   • コマンドをバックグラウンドで開始します。
   • 出力をポーリングします。サインインを求めるメッセージ（新しい CLI では Sign in with one click: <url>、古いものでは Sign in at: <url> / Enter this code: <code>）が表示されたら、すべての処理を直ちに止め、その内容を一言一句変えずにユーザーに伝えます。要約、短縮、後回しはしないでください。ワンクリック URL がある場合はそれを優先し、ない場合は URL とコードを一緒に伝えます。今すぐリンクを開くようユーザーに伝えてください。
   • コマンドを実行したままにして、ポーリングを続けます。ユーザーがサインインを完了すると、同じプロセスがセッションを引き継ぎ、自動的にデプロイを続行します。その後、以下のデプロイルールに従って確認します。
2. バックグラウンド実行に非対応 — 事前に伝え、最長のタイムアウトを使用：
   • 実行前に、ユーザーに次のように伝えます："サインインリンクが表示されます。取得でき次第すぐにお見せします。コードの有効期限は10分ですので、速やかに認証を完了してください。"
   • 使用できる最長のタイムアウトを設定して実行します。
   • サインインが完了する前にコマンドがタイムアウトするか終了した場合、表示されたコードは監視されなくなります。リンクが表示されていた場合は参考のために伝えたうえで、直ちにコマンドを再実行し、新しいリンクを伝えて、必ず最新のリンクを使うようユーザーに案内します。
3. 絶対に、リンクを表示せずにコマンドの完了を黙って待ったり、リンクを伝えてユーザーに操作の機会を与える前にサインイン失敗と報告したりしないでください。

ブラウザー経由のトランスポートでは、これらの対応は不要です。CLI がユーザーのマシン上でブラウザーを開きます。

JSON / CI モードでは自動的にプロンプトが表示されません：railway up --json と railway up --ci は、未認証のユーザーに対してブラウザーを開きません。--json は代わりに構造化されたエラーを出力します：

{"error":"Not signed in.","code":"NOT_AUTHENTICATED","hint":"Run `railway login` to authenticate, then re-run."}

code: NOT_AUTHENTICATED が表示されたら、railway login でユーザーを認証してから、元のコマンドを再試行します。

完全な無人実行（人間が一切関与しない場合）：対話型ログインを実行する代わりに、RAILWAY_API_TOKEN（アカウントスコープ）または RAILWAY_TOKEN（プロジェクトスコープ）を設定します。トークンを持たない新規ユーザーは、人間がいない状態ではサインアップを完了できません。ヘッドレスでアカウントを作成する方法はありません。

エージェント向けツール

決定性が求められる操作には、Railway CLI コマンドを直接使用します。railway agent は、ユーザーが Railway Agent を明示的に求めた場合、自然言語での調査を希望する場合、またはタスクが単一リソースの操作を超える場合にのみ使用します。

以下で Railway のスキル、MCP、認証をセットアップします：

railway setup agent
railway setup agent -y
railway setup agent --remote

railway setup agent -y は、対話型ログインのフローをスキップします。セットアップ後にユーザーが認証されていない場合は、railway login を実行します。

ユーザーが対象のツールを指定した場合は、MCP とスキルを直接インストールまたは更新します：

railway mcp install
railway mcp install --agent codex
railway mcp install --agent cursor --remote
railway skills
railway skills update --agent codex
railway skills remove --agent cursor

対応する対象には、claude-code、cursor、codex、opencode、copilot、factory-droid があります。--remote フラグを指定すると、ローカルの railway mcp stdio サーバーではなく、https://mcp.railway.com を設定します。

以下を使用して Railway Agent のチャットを開始します：

railway agent
railway agent -p "why is my service crashing?"
railway agent -p "summarize the deployment status" --json
railway agent --list --json
railway agent --thread-id <thread-id>

railway agent には、railway login によるユーザーの OAuth 認証が必要です。プロジェクトトークン（RAILWAY_TOKEN）は Railway Agent のチャットではサポートされていません。エージェントコマンドを利用できない場合は、railway upgrade --yes でアップグレードします。

よくあるクイック操作

これらは、リファレンスを読み込まずに対応できるほど頻繁に行われる操作です。作業がプラットフォームに限定されており、対応する MCP ツールが利用可能な場合は、そのツールを使用します。それ以外の場合は CLI を使用します：

railway status --json                                    # current context
railway whoami --json                                    # auth and workspace info
railway project list --json                              # list projects
railway service list --json                              # services in current environment (verify before retrying `add`)
railway add --database <type> --json                     # add one database; ALWAYS pass --json
railway add --service <name> --json                      # add empty service; ALWAYS pass --json
railway variable list --service <svc> --json             # list variables
railway variable set KEY=value --service <svc>           # set a variable
railway logs --service <svc> --lines 200 --json          # recent logs
railway metrics --service <svc> --since 1h --json        # resource and HTTP metrics summary
railway up --detach -m "<summary>"                       # deploy current directory (returns at QUEUED — verify before reporting)
railway deployment list --json                           # poll newest deployment status after a detached up
railway bucket list --json                               # list buckets in current environment
railway bucket info --bucket <name> --json               # bucket storage and object count
railway bucket credentials --bucket <name> --json        # S3-compatible credentials

ルーティング

簡単な操作を超える場合は、ユーザーの意図に合ったリファレンスを読み込んでください。必要なものだけを読み込みます。通常は1つで十分で、多くても2つです。

意図	リファレンス	用途
データベースを分析する（「analyze <url>」、「analyze db」、「analyze database」、「analyze service」、「introspect」、「check my postgres/redis/mysql/mongo」）	analyze-db.md	データベースのイントロスペクションとパフォーマンス分析。analyze-db.md から、DB 固有のリファレンスに案内されます。Railway のデータベースサービスの URL とともに「analyze」が指定された場合、ステータス／操作のルートよりもこちらを優先します。
リソースを作成または接続する	setup.md	プロジェクト、サービス、データベース、バケット、テンプレート、ワークスペース
コードをデプロイする、またはリリースを管理する	deploy.md	デプロイ、再デプロイ、再起動、ビルド設定、モノレポ、Dockerfile
設定を変更する	configure.md	環境、変数、設定パッチ、ドメイン、ネットワーキング
ヘルス状態を確認する、または障害をデバッグする	operate.md	ステータス、ログ、メトリクス、ビルド／ランタイムのトリアージ、復旧
サンドボックスを使用する、またはリモートでビルドする（「sandbox」、「scratch environment」、「ephemeral box」、「build remotely」、「remote build」、「run this remotely」）	sandbox.md	サンドボックスの作成／フォーク、リモートでのコマンド実行、リモートテンプレートのビルド、ポートフォワーディング、破棄。Priority Boarding でサンドボックスを有効にする必要があります。利用できない場合は、有効にするようユーザーに案内してください。
API、ドキュメント、コミュニティへのリクエスト	request.md	Railway GraphQL API のクエリ／ミューテーション、メトリクスのクエリ、Central Station、公式ドキュメント

リクエストが2つの領域にまたがる場合（たとえば、「デプロイしてから、正常に動作しているか確認する」）、両方のリファレンスを読み込み、1つの応答にまとめてください。

実行ルール

1. 利用可能な MCP ツールに対応するプラットフォーム操作には、Railway MCP を使用してください。
2. 現在のリポジトリ、ローカルシェル、SSH、データベーススクリプト、または MCP でカバーされていない機能が必要なワークフローには、ローカル CLI を使用してください。
3. MCP でも CLI でも実行できない操作には、scripts/railway-api.sh を使用してください。
4. 確実に解析できるよう、利用可能な場合は --json 出力を使用してください。
5. 変更を加える前にコンテキストを確認してください。操作対象のプロジェクト、環境、サービスを把握してください。
6. 破壊的な操作（サービスの削除、デプロイの削除、データベースの削除）を行う場合は、実行前に意図と影響を確認してください。
7. 変更後は、読み取りコマンドまたは MCP の読み取り操作で結果を確認してください。
8. 終端の SUCCESS を確認せずに、デプロイが成功したと報告してはいけません。 railway up --detach が戻ってきても（「Build queued」と表示されます）、またストリーミング中の railway up がシェルのタイムアウトで中断されても、確認できるのはビルドが開始されたことだけです。最新のデプロイの status が SUCCESS（デプロイ済みとして報告）、または FAILED／CRASHED（operate.md に従ってトリアージし、成功したとは主張しない）になるまで、railway deployment list --json をポーリングしてください。ストリーミング中の up が自動的に終了した場合、その終了コードを正式な結果とします。終了コード 0 はデプロイ済み、終了コード 1 は失敗です。

ユーザーのみが実行するコマンド（絶対に直接実行しないでください）

これらのコマンドはデータベースの状態を変更し、ユーザー自身がターミナルで実行する必要があります。Bash では実行しないでください。代わりにコマンドを提示し、ユーザーに実行を依頼してください。

コマンド	ユーザーのみが実行する理由
python3 scripts/enable-pg-stats.py --service <name>	shared_preload_libraries を変更するため、データベースが再起動される場合があります
python3 scripts/pg-extensions.py --service <name> install <ext>	データベース拡張機能をインストールします
python3 scripts/pg-extensions.py --service <name> uninstall <ext>	データベース拡張機能を削除します
ALTER SYSTEM SET ...	PostgreSQL の設定を変更します
DROP EXTENSION ...	データベース拡張機能を削除します
CREATE EXTENSION ...	データベース拡張機能をインストールします

これらの操作が必要な場合：

1. コマンドの内容と副作用（再起動が必要になる場合など）を説明します
2. ユーザーが実行する正確なコマンドを提示します
3. ユーザーが実行したことを確認するまで待ちます
4. 読み取り専用のクエリで結果を確認します

構成パターン

複数ステップのワークフローは、自然な手順に沿って進めます。

• オブジェクトストレージの追加：セットアップ（バケットを作成）、セットアップ（認証情報を取得）、設定（アプリサービスに S3 変数を設定）
• 初回デプロイ：セットアップ（プロジェクトとサービスを作成）、設定（変数とソースを設定）、デプロイ、運用（正常な状態を確認）
• 障害の修正：運用（ログを調査）、設定（設定や変数を修正）、デプロイ（再デプロイ）、運用（復旧を確認）
• ドメインの追加：設定（ドメインを追加し、ポートを設定）、運用（DNS とサービスの正常性を確認）
• ドキュメントから操作へ：リクエスト（ドキュメントから回答を取得）、関連する運用リファレンスに案内

手順を組み合わせる場合は、すべてのステップを網羅した一つの統合された回答を返します。ユーザーに各ステップを個別に実行するよう求めないでください。

セットアップの判断フロー

ユーザーが何かを作成またはデプロイしようとしている場合は、現在のコンテキストに基づいて適切な操作を判断します。

1. 意図が deploy-from-cwd または signup-from-cwd の場合は、railway whoami を省略し、意図に基づくルーティング に従って railway up（または railway up -y）を直接実行します。これにより、サインアップ、プロジェクト作成、サービス作成、デプロイを一連の流れで処理できます。それ以外の、ワークスペースやアカウントのコンテキストを先に確認する必要があるセットアップでは、railway whoami --json を実行します。認証エラーで失敗した場合、ユーザーにトークンがありません。アカウントの作成とサインイン に案内します。
2. 現在のディレクトリで railway status --json を実行します。
3. リンク済みの場合：既存のプロジェクトにサービスを追加します（railway add --service <name>）。ユーザーが明示的に「新しいプロジェクト」または「別のプロジェクト」と指定しない限り、新しいプロジェクトは作成しないでください。
4. 未リンクの場合：親ディレクトリを確認します（cd .. && railway status --json）。
   • 親ディレクトリがリンク済み：モノレポのサブアプリである可能性が高いです。サービスを追加し、rootDirectory をサブアプリのパスに設定します。
   • 親ディレクトリも未リンク：railway list --json を実行し、ディレクトリ名と一致するプロジェクトを探します。
     • 一致するプロジェクトが見つかった場合：そのプロジェクトにリンクします（railway link --project <name>）。
     • 一致するプロジェクトが見つからない場合：新しいプロジェクトを作成します（railway init --name <name>）。
5. ワークスペースが複数ある場合は、railway whoami --json の名前を照合します。

命名のヒューリスティック：「flappy-bird」や「my-api」などのアプリ名は、プロジェクト名ではなくサービス名です。プロジェクト名にはディレクトリ名またはリポジトリ名を使用します。

応答形式

すべての運用に関する回答では、次の内容を返します。

1. 実施した内容（操作と範囲）。
2. 結果（ID、ステータス、主な出力）。
3. 次に行うこと（またはタスクが完了したことの確認）。

出力は簡潔にしてください。実施内容の理解に役立つ場合に限り、コマンドの実行結果を含めてください。