第4章 · Lesson 14 / 17

読む仕組みと拡張

実行環境と Secrets

Agent に『仕事場』を渡す

  • 目安 14 分
  • 進捗 14/17

このレッスンのゴール

  • なぜ環境構築が Cloud Agent の勝敗を分けるか説明できる
  • Secrets をリポジトリに置かない理由を理解する
  • 環境がないときに起きる失敗を見分けられる

環境とは何か

人が開発するとき、PC に言語ランタイムや依存パッケージを入れ、起動コマンドを覚えます。Cloud Agent にも同じものが必要です。公式ドキュメントも、環境を渡さないことは『エンジニアに PC を渡さない』ことに近い、と表現しています。

依存のインストール、起動方法、必要な秘密情報、ネットワーク。これが揃うほど、Agent は『書いたつもり』ではなく『動かして確認した』まで行けます。

環境の作り方は3系統

公式のセットアップでは、だいたい次のどれか(または組み合わせ)で仕事場を用意します。名前を覚える必要はありません。『環境がない』と『環境の作り方を選ぶ』は別問題だと知っておくと、開発者との会話が速くなります。

  • Agent 主導のセットアップ: Agent に必要なものを入れてもらい、あとで保存する
  • 保存済みスナップショット: 一度整えた状態を使い回す
  • Dockerfile / .cursor/environment.json: リポジトリ側に環境定義を置く

Secrets の扱い

API キーやトークンは、コードやチャットに貼らず、Web の Cloud Agents 設定(cursor.com/dashboard/cloud-agents)の Secrets へ入れます。スマホアプリからは主に使う側で、秘密情報の登録や環境そのものの編集は Web 側の作業です。

非開発者ができる貢献

環境そのものの作成は詳しい人が担うことが多いです。あなたは、『どの外部サービスが必要か』『プレビューで何ができれば十分か』『Secrets に入れるべき値の名前(値そのものではない)』を言語化することで貢献できます。

理解チェック

  • 環境不足の症状(インストール失敗、テスト不能、起動不能)を想像できる
  • Secrets を GitHub のファイルに置かないと言える
  • 環境の用意に『Agent 主導 / スナップショット / 定義ファイル』があると言える

実践

チームの Cloud Agent 環境に何が入っているか(または不足か)を1つ確認する。分からなければ『環境の有無』を開発者に質問する。

いま身についている開発者スキル

開発環境 / シークレット管理 / twelve-factor 的発想