Codex Cloudを試してみた。最近ではCloud Sessionsもスタートしつつある。 これはCodexにお任せすると、勝手にクラウド環境でGitHubのイシューの修正からPRまで全部やってくれるみたいな機能。 例えば、アプリを作ってきた時のメモを夜にアップし、次の夜に帰宅後、飯食いながらAIに勝手に一気に修正してもらう、みたいなのができる。

Museやdots、Grok botのような自立型エージェントが発表された今、もはや旧来型の「コードをプログラマが書く」は本当になくなる方向にあるのではないか（少なくともモダンな開発環境では）と感じる。

が、まだまだ神通力とはいかない。「あるぇ～」って思ったところがあったのでメモ。

注意点1: gitconfig

一応、私は体裁上GitHubではニックネームで活動している。Eメールもnoreplyを使用している。

が、Codex Cloudではデフォルトでgitのプロフィールは本名と登録Eメールアドレスを使うようだ。
これは盲点で、ForkのようなGUIクライアントを使ってたからサクッと気付けたが、マジカって感じだった。

注意点2: 開発環境

使ってみたリポジトリはRust + Typescriptで構築されたTauriアプリです。

開発環境を作るときは、AIがGitHubリポジトリを読んで勝手にいい感じに作ってくれる…ように見えたが、 なんとRustはインストールされているのに端末で読んでない（PATH通ってない）っぽいことが分かった。

これはCodex君が「ワイ、cargo使えないからビルドとか試してないんよ」と修正で無邪気に言ってきて分かった。

結局のところプロンプトを打つことによって分かったが、環境を作る時不完全である可能性があることに注意が必要であった。自身が予知できるのならば、環境診断やスモークテストを行わせるような何かを環境公開の前にCodexにお願いすることはできたらやった方がいいのだろう。

対策

対策としてはAGENTS.mdにこんな感じで書くと、確認を取ってくれるようになった。

## クラウド環境でAIが作業する場合

**Codex Cloud**など、ユーザーの管理下にないクラウド環境でソースコードを変更する場合は、作業開始時に以下を確認し、その結果を以後の作業でも踏まえてください。
ユーザーのPCやWSLなど、ローカル環境で作業する場合、このセクションの確認は不要です。

- `node`と`cargo`が使用できることを確認してください。
- `git config`を確認し、コミットに使われる名前とメールアドレスが以下の条件を満たしていることを確認してください。期待する著者情報は、コミット`xxxxxxxx`のAUTHORを参考にしてください。
  - メールアドレスは`noreply`のものを使用してください。
  - 名前は原則として`shimarisu_121`を使用し、本名の使用は避けてください。外部コントリビューターや外部ツールによるコミットは、この名前の条件の対象外です。
- 名前やメールアドレスが上記の条件を満たしていない場合は、コミットせず、ユーザーに対応を確認してください。

skillも作ってみた

流行りのスキルも作ってみた。hogeのところはぼかしなので御愛嬌を。 スキルはAIと共作すると良い。とうか、自前で書くのはなんだかんだ難しいので、AI君がベースを提案してくれたほうが早い。スキルを投げると、かなり良さげなフローでやってくれた。

以下はスクリプトを叩いて、アプリバージョンを更新する作業。
ぶっちゃけ、こんなの自分でやったほうが早いのだが、滅茶苦茶優秀でさすがに、安心君というか、私のおとぼけな性格を考慮すると、頭が下がるばかりなくらい丁寧にやってくれる。

---

name: hoge-app-version-release
description: hoge（hoge-app）のバージョン更新コミットとタグを作成し、ユーザー承認後にプッシュする。アプリのリリースバージョン更新に使い、依存パッケージの更新には使わない。
---

# hogeのバージョン更新

このワークフローに必要なGit操作は、ユーザーの明示的な許可により、AGENTS.mdのGit操作禁止の例外として実行できる。プッシュには後述の承認が必要。

## 1. mainの最新コミットを確認する

- ルートで `git status --short`、`git branch --show-current`、`git remote -v` を確認する。
- 現在のブランチが `main` であることを確認する。別ブランチなら止めて状況を伝え、勝手に切り替えない。
- `git fetch origin` 後、`git rev-parse HEAD` と `git rev-parse origin/main` が一致することを確認する。リモート名が異なる場合は確認したmainの追跡先を使う。
- fetch失敗時は最新と判断しない。不一致なら遅れ・先行・分岐を伝えて止める。自動的なpull・reset・rebaseはしない。
- 未コミット変更・ステージ済み変更は混ぜない。ユーザーが今回のために編集した `package.json` のversionだけなら引き継いでよい。それ以外の変更があれば状況を伝え、解消されるまで待つ。
- 開始時のHEADとHEAD内のversionを控える。履歴の参考は `git show xxxxxxx`。履歴内のバージョン値は流用しない。

## 2. ユーザーによるバージョン編集を待つ

更新先はユーザーが決定し、ユーザー自身が `package.json` のversionを編集する。AIは更新先を決めず、このフィールドを代わりに書き換えない。

一度だけ、次のように促して応答を待つ。

> package.jsonのversionを希望するバージョンに更新し、保存後に「更新しました」と報告してください。
- 完了報告まで同期・コミットへ進まない。待機時間の経過を完了報告とみなさない。
- 同じ作業の会話ですでに編集と完了報告が済んでいれば、再度促さずファイルを確認して続ける。
- 報告後にファイルを読み直し、有効なSemVerであり、HEADのversionから上がっていることを確認する。未変更・不正な値なら具体的な問題を伝え、訂正を待つ。
- この値を以後のバージョンとタグ `v<version>` の唯一の根拠にする。

## 3. 同期して確認する

プロジェクトルートで順に実行する。

```sh
pnpm sync-version
pnpm format
```

- 失敗時はコミットせず、原因を解消してから続ける。
- `git diff` と `git status --short` を確認する。対象は `package.json`、`src-tauri/tauri.conf.json`、`src-tauri/Cargo.toml`、`src-tauri/Cargo.lock`。
- 4ファイルのアプリバージョンが一致することを確認する。Cargo.lockは `hoge` パッケージを確認し、依存パッケージの更新が混ざっていないかも確認する。
- フォーマットによる差分も確認する。無関係な変更は含めず、ユーザーの変更を勝手に破棄しない。
...

正直AIを使った開発はノウハウが必要だが、少しだけAIの気持ちが分かった気がした。

これからの時代、「マークダウン」がプログラミング言語になる

これやっててマジで思いました。マークダウンが書けるということは、以前より遥かにましてAI時代ではスキルです。

なぜなら、AIへの指示・定義は、基本的にマークダウンであることがベストプラクティスと完全に化しているから。普通のプロンプトを与えて出力を見るみたいなレベルなら良かったんだけど、skillやagents（サブエージェント）を発火させて、目指したい方向性に持っていく、丁寧にAIに仕事をさせる、みたいなのは完全にマークダウンがメイン言語になってるっぽいんですよね。

私はそこそこ慣れたと思うから、割と逆に染まってて良かったっていう。書けない人、思ったよりかなりいますからね。