はじめに
こんにちは！個人開発で Flutter アプリを開発している YOKKO です。
PC がない環境でもアイデアを思いついたらそれを実装し、実機で確認できるようにしたいと思い、Codex in Slack を用いた実装環境を構築しました。
今回は、HimaLinkというアプリを例に挙げながら、Codex in Slack での依頼から実装、実機確認までの流れを自動化する方法をご紹介します。
実際のフロー
SlackでCodexに実装したい機能を伝える→実装が完了する
GithubActionsのCI/CDパイプラインで自動ビルド、FirebaseDistributionに自動アップロード
実際に作成された機能（ブロック解除の確認ダイアログ）
この記事でわかること
- Codex in Slack の設定方法（Slack 連携、環境作成、Flutter Test 環境の構築）
- Codex in Slack での依頼フローの実践方法
- 実装から実機確認までの流れ
プロジェクト概要
HimaLink のプロジェクトは Flutter クライアントと Firebase Functions バックエンドを 1 つのリポジトリで管理するモノレポ構成にしています。
このプロジェクトでは Spec Driven Development(仕様駆動開発) を前提として開発を進めており、Codex in Slackからの依頼でもプロジェクトのルール（AGENTS.md や .codex/rules/codex.md）によって、Spec Driven Development の原則に従って動作するように設定しています。
これにより、仕様と実装の整合性を保ちながら、Slack で指示したことがすぐに実装され、実機で確認できることを実現しています。
本記事では、Flutter アプリでも活用できるように整備した Codex in Slack の設定方法と運用フローを紹介します。
Codex in Slack の設定
Codex in Slack を使用するには、まず Codex Cloud Tasks の設定と Slack 連携が必要です。以下、設定手順を説明します。
1. Codex Cloud Tasks の設定
Codex in Slack を使用するには、Codex Cloudの設定が必要です。
Codex Cloud は、クラウドコンテナでコードを読み取り、変更し、実行できる環境を提供します。
-
Codex にサインアップ: Codex にアクセスし、Plus、Pro、Business、Enterprise、または Edu プランにサインアップします（詳細は料金を参照）
- 一部の Enterprise ワークスペースでは、管理者による設定が必要な場合があります
-
GitHub 連携: Codex の設定画面で GitHub を連携します
- Codex がリポジトリのコードを読み取り、変更し、プルリクエストを作成できるようになります
- Codex がリポジトリのコードを読み取り、変更し、プルリクエストを作成できるようになります
2. Slack 連携の設定
- Codex の設定画面を開く: Codex の設定画面にアクセスします
-
Slack 連携を有効化: 「コネクター」セクションで「Slack」の「さらに接続する」ボタンをクリックします
- Slack ワークスペースの承認: Slack ワークスペースの管理者の承認が必要な場合があります
-
チャンネルに追加: 使用したい Slack チャンネルに
@Codexを追加します
参考: Codex in Slack の公式ドキュメントも参照してください。
3. 環境の作成
Codex Cloud Tasks で環境を作成することで、Slack からの依頼を処理できるようになります。
3.1 基本設定
-
環境作成画面を開く: Codex の設定画面で「環境」→「+ 環境を作成する」をクリックします
-
GitHub 組織を選択: 「GitHub 組織」から対象の組織を選択します（例:
yokkomystery） -
リポジトリを選択: 「リポジトリ」から対象のリポジトリを選択します（例:
yokkomystery/HimaLink） -
名前を設定: 「名前」に環境名を入力します（例:
HimaLink）- 最大 64 文字まで入力可能
-
説明を設定: 「説明」に環境の説明を入力します（例:
HimaLink プロジェクトの開発環境）- 最大 512 文字まで入力可能
- 最大 512 文字まで入力可能
3.2 コードの実行設定
コンテナ画像:
-
universal: Ubuntu 24.04 をベースにした画像
- 詳細は openai/codex-universal を参照
- リポジトリは
/workspace/HimaLinkに複製されます - ワークスペースディレクトリは
/workspace/HimaLinkです
プレインストールされたパッケージ:
universal イメージには以下のパッケージがプリインストールされています（2025/11/17 時点）：
Flutter SDK はプリインストールされていません。Flutter プロジェクトを使用する場合は、セットアップスクリプトで Flutter SDK をインストールする必要があります。
セットアップスクリプト:
共通パッケージマネージャーに対するインストールコマンドを実行します。Codex Cloudでは、各タスクごとにサンドボックス化されたクラウドコンテナがプロビジョニングされ、このセットアップスクリプトが実行されます。
HimaLink プロジェクト（モノレポ構成）の場合、以下のセットアップスクリプトを設定しています：
# リポジトリは /workspace/HimaLink に複製されている
cd /workspace/HimaLink
# Flutter SDK のインストール（universal イメージには Flutter がプリインストールされていません）
FLUTTER_VERSION="3.32.4"
FLUTTER_SDK_DIR="/opt/flutter"
if [ ! -d "$FLUTTER_SDK_DIR" ]; then
echo "Installing Flutter SDK..."
cd /tmp
wget -q "https://storage.googleapis.com/flutter_infra_release/releases/stable/linux/flutter_linux_${FLUTTER_VERSION}-stable.tar.xz" -O flutter.tar.xz
tar xf flutter.tar.xz
sudo mv flutter $FLUTTER_SDK_DIR
# Git の所有権エラーを解決（sudo mv で所有権が root になった場合の対処）
git config --global --add safe.directory $FLUTTER_SDK_DIR
fi
# Flutter SDK のパスを設定（セッション全体で有効にするため、~/.bashrc にも追加）
export PATH="$FLUTTER_SDK_DIR/bin:$PATH"
echo "export PATH=\"$FLUTTER_SDK_DIR/bin:\$PATH\"" >> ~/.bashrc
# Git の所有権エラーを解決（念のため）
git config --global --add safe.directory $FLUTTER_SDK_DIR
# Flutter SDK の確認
flutter --version
# Flutter フロントエンドの依存関係をインストール
cd /workspace/HimaLink/HimaLink-frontend
flutter pub get
# Node.js バックエンドの依存関係をインストール
cd /workspace/HimaLink/HimaLink-backend
npm install
環境変数・シークレット・その他の設定:
-
環境変数: 必要に応じて環境変数を追加します（例:
PRODUCTION=false,FLUTTER_VERSION=3.32.4） - シークレット: 機密情報（API キーなど）は「シークレット」に追加します。シークレットは環境変数として参照できますが、値は表示されません
- コンテナのキャッシュ: セットアップスクリプト実行後の状態をキャッシュして、コンテナの起動を高速化します。推奨: 有効化
- エージェントのインターネットアクセス: セットアップ後はインターネットへのアクセスが無効になります（デフォルト）。Codex が使用できるのは、セットアップスクリプトによってインストールされた依存関係のみになります
設定のポイント:
-
Flutter SDK のインストール:
universalイメージには Flutter SDK がプリインストールされていないため、セットアップスクリプトでインストールする必要があります。上記のスクリプトは、Flutter SDK が存在しない場合に自動的にインストールします。 -
PATH の設定: Flutter SDK のパスを
~/.bashrcにも追加することで、セッション全体で Flutter コマンドが使用可能になります。これにより、Codex がテストを実行する際にも Flutter CLI が認識されます。 -
パスの設定: リポジトリは
/workspace/<リポジトリ名>に複製されるため、セットアップスクリプトでは適切なパスを指定してください。Flutter プロジェクトはHimaLink-frontendディレクトリ内にあるため、cd /workspace/HimaLink/HimaLink-frontendで移動してからflutterコマンドを実行します。
3.3 ターミナルでの事前確認
環境設定画面の「ターミナル」ボタンから、セットアップスクリプトが正しく動作するか事前に確認できます。
確認手順:
- ターミナルを開く: 環境設定画面の「ターミナル」セクションで「対話型ターミナルを接続」をクリックします
- セットアップスクリプトの実行: ターミナルが開いたら、セットアップスクリプトが自動的に実行されます
- エラーの確認: エラーが発生した場合は、エラーメッセージを確認してセットアップスクリプトを修正します
3.4 環境の確認
環境作成後、環境一覧に表示されます。以下の情報が確認できます：
- 名前: 設定した環境名
- リポジトリ: 連携したリポジトリ
- タスク数: 実行されたタスクの数
- 作成者: 環境を作成したユーザー
- 作成日時: 環境の作成日時
4. Codex が環境を選択する仕組み
Codex は、Slack での依頼内容を基に、適切な環境を自動選択します：
- Codex は、アクセス可能な環境を確認し、依頼内容に最も適した環境を選択します
- 依頼内容が曖昧な場合は、最近使用した環境にフォールバックします
- 特定の環境を指定したい場合は、依頼時に環境名を明示できます（例:
@Codex fix the above in yokkomystery/HimaLink）
Codex in Slack での依頼フロー
HimaLink では、Codex in Slackからの依頼でも Spec Driven Development の原則を守るためのルールをプロジェクトのルール（AGENTS.md や .codex/rules/codex.md）で定めています。
1. Slack で Codex に依頼
Slack のチャンネルで @Codex をメンションし、実装を依頼します（Codex in Slack の設定方法を参照）：
例: ブロック解除確認ダイアログ機能の場合
@codex
ブロック解除確認ダイアログを実装したい
Environment: Himalink
Feature/Spec: ブロック解除確認ダイアログ / 新規（/kiro/spec-initから）
Scope: 解除ボタン押下時に「はい／いいえ」ダイアログ表示、はいなら解除処理、いいえならキャンセル
Background: ユーザーがブロック解除操作をする際、誤操作防止のため確認ダイアログを表示したい
Request: Spec初稿 + 実装
2. Codex の応答フロー
ログを確認したところ、Codex は、プロジェクトのルール（AGENTS.md や .codex/rules/codex.md）に従って、以下の流れで対応をしていました
実際の Codex の作業内容:
上記の依頼を受けた Codex は、以下の作業を自動的に実行します：
-
プロジェクトルールの確認:
AGENTS.mdを読み込み、Spec Driven Development の原則を確認
-
既存 Spec の確認:
HimaLink-frontend/specs/を確認し、既存の Spec 形式を把握
-
Spec の作成:
specs/profile-user-management/unblock-confirmation-dialog/spec.mdを作成
-
実装の実行:
- ヘルパー関数
lib/shared/widgets/unblock_confirmation_dialog.dartを作成 - 4 つの画面（プロフィール画面、ブロック済みユーザー一覧、タイムラインの投稿/コメント）に確認ダイアログを追加
- 全言語対応のローカライゼーションキーを追加（日本語、英語、韓国語、中国語簡体字・繁体字）
- ヘルパー関数
-
テストの作成・実行:
test/features/profile/unblock_confirmation_dialog_test.dartを作成し、テストを実行してパスを確認
-
コミット: すべての変更をコミット
作業時間: 約 20 分（Spec 作成から実装完了まで）
3. 実装から実機確認までの流れ
Codex が実装を完了すると、PR を作成できます。
差分なども確認可能です。
私の場合、PR作成後にGitHub Actionsで以下のフローを実現しているため、PCがなくてもそのままインストール→実機確認までを可能としています。
GitHub Actions の詳細な設定方法については、別記事にて記載しようと思います。
特定のラベル付与をトリガーとし、CI/CD 実行
↓
テスト、静的解析の実行
↓
ビルド
↓
Firebase App Distribution への自動アップロード
まとめ
本記事では、HimaLink プロジェクトで実践している Codex in Slackの設定と運用方法を紹介しました。
主なポイント
- Codex in Slack の設定: Codex Cloud Tasks の環境作成と Slack 連携により、Slack から直接実装を依頼できる環境を構築
-
Flutter プロジェクトの環境構築:
universalイメージには Flutter SDK がプリインストールされていないため、セットアップスクリプトで Flutter SDK をインストールする必要がある -
Spec Driven Development との連携: プロジェクトのルール（
AGENTS.mdや.codex/rules/codex.md）により、Codex が Spec Driven Development の原則に従って動作するように設定 - 実装の自動化: Codex が Spec を作成してから実装を進めることで、仕様と実装の整合性を保ちながら開発できる
成果
- 開発速度の向上: Slack で指示したことが、すぐに実装され、実機で確認できるようになった
- 仕様と実装の整合性: Spec Driven Development を前提とすることで、仕様と実装の整合性を保ちながら開発できる
- 運用の効率化: PC が開けない環境でも、Slack から実装を依頼し、実機で確認できるワークフローを実現