Claude Codeを Bitbucket・固定IP環境で動かすために実装したこと ＜2026年秋＞

リックソフトの開発部では、Jiraや Confluenceを使った業務をAIエージェントで支援するため、Claudeの実行環境を整備しています。

Claude Codeのクラウドセッションを利用するにあたり、課題になったのが Bitbucketのコード資産と IP制限のあるサービスへの接続でした。そこで、Self-hosted Runnerを使った実行基盤を GCP上に構築しました。

この記事では、今回選んだ構成と追加した実装、残っている制約を紹介します。

Self-hosted Runnerとは

Claude Codeは、手元の PCのほか、Anthropicが提供するクラウド環境でも動作します。クラウド上のセッションを使えば、PCを起動し続けなくても作業を進められます。例えば「始業前に時間のかかる調査や検証を開始するようスケジュールし、始業直後に結果を確認する」といった使い方ができます。

このクラウドセッションの実行先を、自社で管理する環境に切り替える仕組みが Self-hosted Runnerです。利用者は Claude Codeの画面で実行環境を選び、自社で用意した Runnerに作業を依頼します。

自前で環境を管理できるため、必要なソフトウェアの追加、接続元IPの固定、メモリ保存先の指定など、業務要件に合わせたカスタマイズが可能です。ただし、モデルの推論自体は Anthropic側で行われるため、すべての処理が自社環境内で完結するわけではありません。

今回はこの仕組みを使い、Bitbucketのコード資産と、IP制限のある Jira／Confluenceを利用できる実行基盤を GCP上に構築しました。

実行環境に求めたこと

今回の要件は、次の四つです。

• Bitbucketにあるリポジトリを取得し、作業結果を pushできること
• 固定IPから Jira／Confluenceや社内向けパッケージにアクセスできること
• 利用者の PCを起動し続けなくても作業できること
• セッションをまたいだメモリを利用できること

なお、モデルの推論は Anthropic側で行われるため、今回の取り組みはデータの完全な自社内完結を目指したものではありません。

構成概要

実行基盤は GCP上に構築しました。主な構成は次のとおりです。

Runnerからの通信は Cloud NATを経由させ、出口IPを固定しています。この IPを接続先の許可リストへ登録することで、Jira／Confluenceや社内向けパッケージにアクセスできるようにしました。

実行環境はセッションごとに起動する

基本単位は「1セッション＝1 Cloud Run Job実行」です。GCE上のオーケストレーターが作業の到着を待ち、必要に応じて実行用コンテナを起動します。

オーケストレーターには、常駐プロセスをできるだけ低コストで動かすため、GCEの小さな VMを採用しました。セッションの実行先には、コンテナ内の一時ファイルの破棄など、実行環境の後始末を自前で管理する手間を省ける Cloud Run Jobsを採用しています。必要なときだけ実行環境を起動することで、ランニングコストも抑えます。

この構成では、セッション開始時にコンテナの起動待ちが発生します。必要なソフトウェアをあらかじめ組み込めば、作業中のセットアップを減らせますが、イメージが大きくなると起動に時間がかかり、短い作業を依頼しづらくなります。そこで、Jira／Confluence操作向けの軽量環境と、ビルドや検証用ソフトを含む開発環境の2種類に分けています。

また、ターン終了後も追加の指示を待つ間は Jobが動作し、課金が続きます。追加の指示にすぐ対応できるよう、どれだけ環境を保持するかは、コストと合わせて調整する必要があります。

認証情報は利用者とリポジトリの組で渡す

接続先やトークンを利用者自身で登録できるよう、管理画面を用意しました。Googleアカウントでログインすると、自分が登録した認証情報や環境変数などの設定をリポジトリごとに確認・追加・編集・削除できます。

利用者が管理画面で設定を登録し、Runnerがセッション開始時に該当する設定を取得します。受け取った特定の設定は、Gitの認証設定、パッケージ取得用の設定として展開します。

セッション開始時に Bitbucketからコードを取得する

今回は Self-hosted Runnerの checkoutフックを使い、標準のリポジトリ取得処理を差し替えました。

checkoutフックで実行するスクリプトは、環境変数 CLAUDE_RUNNER_REPO_URLで渡される GitHubの URLからリポジトリ名を取り出し、同名の Bitbucketリポジトリの URLを組み立てます。その後、CLAUDE_RUNNER_CHECKOUT_PATHで指定された作業ディレクトリに、git init、git fetch、git checkoutでコードを用意します。

このとき Gitの originも Bitbucketに設定するため、作業結果の push先も Bitbucketになります。認証には、管理サービスから取得した利用者の認証情報を使います。

ただし、開始画面での選択用として、GitHubのアカウントと同名のリポジトリは引き続き必要です。実際の読み書きを Bitbucketに向けられても、GitHub側の管理が残る点は、この方式の制約です。

セッション終了時に作業を退避し、再開時に復元する

セッションごとに実行環境を破棄するため、途中の作業を残す仕組みも必要です。そこで、post-sessionフックを使い、終了時に変更が残っていれば Bitbucketの rescue/<セッションID>ブランチへ pushする処理を追加しました。未コミットの変更は、コミットしてから退避します。

同じセッションが新しい実行環境で再開される際には、checkoutフックがこの救済ブランチを確認します。通常の取得先より救済側の作業が進んでいれば、退避したコミットから復帰します。履歴が分岐している場合は、自動でマージせず停止するようにしました。

ただし、退避には終了フックの実行と pushの成功が必要です。強制終了や通信障害などで保存できなかった変更まで復元できるわけではありません。

Claudeのメモリは実行用コンテナの外に保存する

実行環境を自社で管理することで、セッションをまたいだメモリの引き継ぎも実現しました。

今回は GCSを実行環境にマウントし、Claude Codeの自動メモリの保存先をそこへ向けています。保存先は利用者・リポジトリごとに分け、新しいコンテナで始まったセッションでも、以前の作業で保存したメモリを利用できる構成にしました。

実行用コンテナを使い捨てにしながら、継続して使いたい情報は残せます。メモリの保存先や取り扱いを自分たちで管理できることも、Self-hosted Runnerを使う利点です。

おわりに

今回の構成には、Bitbucketで作業する場合でも GitHubのアカウントとリポジトリが必要で、管理の手間が増えるという使いづらさがあります。また、セッション開始時の起動待ちもあり、短い作業を気軽に依頼するには改善の余地が残っています。

それでも、既存の Bitbucket資産を使い、固定IPから許可されたサービスに接続できるようになったことは、導入する価値がありました。リポジトリの移行やIP制限の緩和をせずに Claude Codeを活用したい場合、Self-hosted Runnerは検討する価値のある選択肢だと思います。