2018年に組んだWindows PCをCodex専用機にしたら、AI開発がかなり楽になった

項目	構成
CPU	Intel Core i5-8400（6コア6スレッド）
メモリ	DDR4-2666 16GB（8GB×2）
ストレージ	Samsung SSD 860 EVO 500GB
マザーボード	GIGABYTE Z370M DS3H
CPUクーラー	Thermalright Assassin King 120 SE
GPU	Intel UHD Graphics 630（CPU内蔵）

ローカルで大規模なAIモデルを動かす用途ではありません。

Codex App、Git、Node.js、VS Code、ブラウザを動かし、クラウド側のAIへ開発作業を依頼する端末として使っています。

この用途では、専用GPUを搭載した最新PCでなくても、今のところ十分に役割を果たしています。

2. Windowsネイティブの開発環境を固定した

Windows側には、主に次のツールをまとめています。

Codex App
Git for Windows
Git Credential Manager
Node.jsとnpm
Visual Studio Code
開発対象のGitHubリポジトリ
ChatGPTへレビューを依頼するためのブラウザ

開発リポジトリはCodex専用のフォルダへまとめ、専用機は別のPCからリモート操作できるようにしています。必要なときだけ接続し、普段使いの環境とは分離しています。

毎回環境を作り直すのではなく、前回の開発状態へ戻るための場所として使っています。

3. AIと人間の役割を分けた

現在の基本的な流れは次のとおりです。

私
  Issueを選び「Issue #Nを実装して」と依頼する

Codex
  Issue確認 → 実装 → テスト → Draft PR作成
  → ChatGPTへレビュー依頼
  → 修正指示があれば対応して再レビュー

ChatGPT
  Issue・差分・CI・残存リスクを確認
  → changes_requested または approved をGitHubへ記録

私
  承認とCI成功を確認して「マージして」と指示する

重要なのは、CodexやChatGPTの画面だけを作業状態の正本にしないことです。

レビュー状態はGitHubのPull Requestコメントへ記録し、マージは別の明示的な指示があるまで実行しないようにしています。

実際に完走したPull Request

専用機で動かした実例として、agent-dev-workflow-liteのPull Request #7があります。

このPull Requestの目的は、次の流れを実際に一度完走できるか確認することでした。

最初の実装
→ ChatGPTがchanges_requestedを記録
→ Codexが指摘を読み取って修正
→ 新しいコミットをpush
→ 再レビュー
→ approved
→ 必須CI成功
→ Codexはマージせず停止
→ 人間の指示でマージ

最初から承認させないテストにした

このPull Requestでは、最初の実装でレビュー指示の前後にある空白を除去する処理を追加しました。

ただし、重複した修正指示を拒否する処理は、あえて最初のコミットには入れませんでした。

ChatGPTのレビューで重複指示への対応をchanges_requestedとして記録し、Codexがその指示を受け取って追加実装する流れを試すためです。

Codexが修正し、別のコミットとして更新した

CodexはGitHub上の修正指示を確認し、次の対応を行いました。

前後の空白を除去した後に同じ内容になる指示を重複として拒否する
duplicate_instructionsというエラーコードで停止する
完全に同じ指示と、空白だけが異なる指示の両方をテストする
正常な指示の順番は維持する

最終的なPull Requestは、2コミット、2ファイル変更、69行追加、8行削除でした。

GitHub上では、2026年7月31日11時36分ごろにPull Requestが作成され、11時54分ごろにマージされています。

CIはNode.js 20・22・24で成功した

修正後のコミットでは、GitHub ActionsのCIがNode.js 20、22、24の3環境ですべて成功しました。

各環境で依存関係の導入、テスト、静的チェックを実行しています。

レビュー状態を示すコメントも最終的にapprovedとなり、その後に人間の明示指示でマージしました。

なお、レビュー状態は一つのコメントを更新し続ける設計です。そのため、現在GitHubで見えるコメントは最終的なapprovedですが、途中では同じコメントがchanges_requestedとpendingへ更新されています。

難しかったこと・うまくいかなかったこと

常時起動にしただけでは開発は自動化されない

専用機を用意すれば、すべて放置できるわけではありません。

Issueの内容、完了条件、レビュー方法、停止条件が曖昧なままだと、AIが長時間動けること自体がリスクになります。

専用機は自動化の本体ではなく、決めた開発フローを継続して動かすための土台です。

ChatGPTの画面をレビュー結果の正本にできなかった

ブラウザ上でChatGPTが「承認しました」と回答しても、その画面だけではCodexが安定して状態を確認できません。

また、コードを修正してコミットが変わった後に、古いコミットへの承認を誤って使う可能性もあります。

そこで、GitHubの一つのコメントに、対象コミットの完全なSHAと次の3状態だけを記録する方式にしました。

pending
changes_requested
approved

コードをpushするたびに対象SHAを更新し、古い承認は使えないようにしています。

自動化を増やしすぎると使いにくくなる

開発フローを考えていると、履歴管理、再起動からの自動復旧、修正回数の制限、バックグラウンド監視などを追加したくなります。

しかし、仕組みを増やすほど保守対象と失敗経路も増えます。

現在は、Issueから承認とCI成功まではCodexに進めてもらい、マージは人間の別指示にする最小構成を選んでいます。

どう判断したか

採用した方法

既存のWindows PCをCodex専用機として再利用する
Windowsネイティブ環境に開発ツールをまとめる
GitHubをIssue、コード、レビュー状態、CIの正本にする
実装・テスト・修正はCodexへ任せる
最終レビューはChatGPT、マージ判断は人間が行う

採用しなかった方法

AI開発のためだけに最新の高性能PCを購入する
WindowsとWSLへ同じ開発環境を二重に構築する
ChatGPTのブラウザ表示だけでレビュー完了を判断する
承認後に自動でマージやデプロイまで実行する

判断基準は、最大限の自動化ではなく、自分の作業を邪魔せず、途中から簡単に再開でき、失敗時にGitHubから状態を確認できることでした。

結果

できるようになったこと

普段使いのPCとCodexの作業が競合しにくくなった
Codexが動いている間も、自分のPCで別の作業を続けられる
Chrome Remote Desktopで専用機へ接続し、前回の続きから再開しやすくなった
Issueから実装、レビュー、修正、CI成功までの流れを実際に完走できた
最終マージだけを人間の判断として分離できた

まだ確認・改善が必要なこと

Windows Updateや再起動後の復旧手順
長期間の常時稼働における温度や消費電力の定量確認
Codexが停止した場合に、GitHub上のどこから再開するかのさらなる簡素化
現在の開発フローを別リポジトリでも再利用しやすくする仕組み

今回の学び

AIの性能だけでなく、AIの作業場所を分けることにも効果がある
普段使いのPCとの競合がなくなるだけで、AI開発の使い勝手は大きく変わりました。
作業状態をGitHubへ残すと再開しやすい
CodexやChatGPTの画面が閉じても、Issue、Pull Request、コミット、CIから現在地を確認できます。
自動化では停止条件の方が重要になる
実装を開始する条件だけでなく、どこで止まり、何を人間へ返すかを決める必要があります。

次にやること

Windows再起動後でも、対象リポジトリと作業中のPull Requestへすぐ戻れる手順を固める
現在のCodex側の実装・修正・再レビューループを再利用可能なSkillとして整理する
別のリポジトリでも同じ流れを試し、リポジトリ固有の指示だけで運用できるか確認する

現時点では、高性能PCへの買い替えや自動マージの追加は優先しません。

まとめ

2018年に組んだWindows PCをCodex専用機として常時起動するようにしたことで、AI開発を始めるまでの準備と、普段使いのPCとの競合が減りました。

一番の効果は、処理速度の向上ではなく、Codexが作業する場所を固定し、前回の続きから再開しやすくなったことです。

実際にPull Request #7では、実装、changes_requested、Codexによる修正、再レビュー、CI成功、承認、人間によるマージまで完走できました。

AI開発専用機に必要なのは、必ずしも最新のGPUや高価なPCではありません。

使っていないPCや古いPCがあるなら、まずはAIエージェントの作業場所として分離し、自分の作業を邪魔せず継続できるか試す価値があります。

くまがいブログ