Codexがアップデートされ、「PC操作まで踏み込んだAI」になった――そんな話を見かけた。
正直、この手の話はこれまでも何度もあった。
だが、実際に触ると“人間がやるだけ”で終わることがほとんどだった。
コードを書くだけではなく、
ファイルを読み、ツールを扱い、作業の流れそのものを進める。
いわゆる“オートパイロット”のような振る舞いをするらしい。
正直に言えば、最初は半信半疑だった。
これまでのAIも「できる」と言いつつ、実際には手を動かすのは人間だったからだ。
だが、Windows版のCodexを実際に触ってみると、印象は少し変わった。
あなたが Plus 以上のユーザーなら、すぐに試すことができる。
今回は、既存のSVGツールを改修させるという、ありがちな作業をやらせてみた。
そこで見えたのは、「コード生成AI」という枠には収まらない、もう一段踏み込んだ挙動だった。
何が変わったのか ─ “PC操作AI”という変化
今回のCodexのアップデートで強調されているのは、単なるコード生成ではない。
ユーザーの操作に寄り添いながら、
ファイルやアプリケーションを扱い、作業を継続する。
つまり、「コードを書くAI」から「作業を進めるAI」へのシフトだ。
たとえば、これまでのAIはこうだった。
- コードは出すが、貼り付けるのは人間
- エラーは教えるが、直すのは人間
- 手順は説明するが、実行するのは人間
一方、今回のCodexは違う。
- ファイルを読み、差分を作る
- 権限や環境の制約を見て、回避手段を選ぶ
- 複数の手順をまとめて実行する
ここで出てくる「オートパイロット」という言葉も、完全自動という意味ではない。
むしろ近いのは、
人間の操作を補完しながら、作業の流れを維持する存在だ。
また、メモリ機能や継続タスクの仕組みも追加されているが、
これも単なる便利機能ではない。
重要なのは、「一回ごとの指示」ではなく、
前後の文脈を持った作業として処理できるかどうかだ。
ここが成立すると、AIの役割は大きく変わる。
単発の指示をこなす道具から、
一連の作業を任せられる相棒に近づいていく。
では実際に、その片鱗はどこまで見えるのか。
次は、既存のツールを使って、実際にCodexに改修をやらせてみる。
実際にやらせてみた ─ 既存SVGツールの改修
今回試したのは、手元にあったSVGジェネレータの改修だ。
もともとこのツールは「丸専用」。
ランダム配置された円を生成して、SVGとして書き出すシンプルなものだ。
ここに対して、Codexにこう指示した。
このSVG背景ジェネレータは現在三角形専用です。
四角形にも対応できるようにしてください。
……と、ここでやらかしている。
実際は「丸専用」なのに、「三角形専用」と書いてしまった。
つまり、仕様説明が間違っている状態だ。
普通に考えれば、この時点でおかしくなる。
- 三角なんて存在しない
- 既存コードと説明が一致しない
- 何をベースに改修すればいいのか曖昧
ところが、Codexの動きは違った。
まず、コードを読み始める。
このファイルは現状 circle を描いています。ユーザー説明と食い違うので〜
指示を鵜呑みにせず、実装を優先して確認している。
そのうえで、
- 図形タイプの選択UIを追加
- 三角形（polygon）と四角形（rect）を切り替え可能に
- 既存の色・透明度・回転・アニメーションを流用
- SVG書き出しとElementor書き出しも維持
といった形で、最小差分で拡張してきた。
さらに面白いのはここからだ。
ローカルのファイルは D:\ 配下にあり、
そのままでは編集権限の制約に引っかかる。
するとCodexはこう動く。
- 作業コピーを作る
- 差分をそこで作成
- 最後に元ファイルへ反映
これも指示していない。
つまり、環境制約を前提に手順を組み替えている。
そしてもう一つ。
元のツールには、書き出したSVGを開くとエラーになる問題があった。
これについても、明示的に指示していないにもかかわらず、
書き出し処理を整理する形で対処が入っていた。
ここまで来ると、やっていることは単純なコード生成ではない。
- 指示を疑う
- 実装を読む
- 制約を回避する
- 周辺不具合を拾う
つまり、これは「コード生成」ではなく「作業の代行」になっている。
ただし、完全ではない。
今回の改修では、
- 元々あった「丸」が消えている
という問題も残った。
このあたりはまだ、
仕様を完全に保持する力は人間側が補う必要がある。
それでも、雑な指示と曖昧な状況の中で、
ここまで筋の通った改修をしてくるのは、正直予想以上だった。
では、この挙動は何なのか。
次は、もう少し踏み込んで「なぜこう動くのか」を見ていく。
Codexは“書く”のではなく“直す” ─ 既存コードへの介入能力
これまでのAIは、ゼロからコードを書くのは得意だった。
だが、実務で本当に価値があるのはそこじゃない。
現場にあるのは、完成されたコードではなく──
誰かが書いて、積み上がって、歪んだ“既存コード”だ。
Codexはここに踏み込んでくる。
実際に動かしてみると分かる。
最初にやるのは生成じゃない。
“読む”ことだ。
- ディレクトリ構造を確認
- 関連ファイルを特定
- 依存関係を洗い出す
まるで新人エンジニアがプロジェクトに入ったときの動きそのものだ。
そして、次にやるのが“変更”。
ここが従来のAIと決定的に違う。
例えば、ちょっとした修正を依頼するとこうなる。
「この関数の挙動を修正してほしい」
これに対してCodexは、
- 該当箇所を探す
- 関連処理を確認する
- 影響範囲を考慮する
- 修正コードを適用する
さらに重要なのは──
“余計なことをしない”ことだ。
これ、地味だがめちゃくちゃ重要。
従来の生成AIは、
- 関係ない部分を書き換える
- 全体を書き直そうとする
- 余計なリファクタを始める
という“暴走”が起きがちだった。
Codexは違う。
「必要な箇所だけを、最小限で直す」
この振る舞いができる。
そしてもう一段上の挙動がある。
修正して終わりじゃない。
- 実行
- エラー確認
- 再修正
ここまで自分で回す。
つまり何が起きているかというと、
“コードを書くAI”ではなく、“保守するAI”になっている
この差は決定的だ。
ゼロから作る能力はデモで終わる。
だが、直せる能力はそのまま実務に刺さる。
ここで初めて見えてくる。
Codexの価値は「生成」ではない。
既存資産に介入できること
この一点で、これまでのAIとは別物だ。
どこまで任せられるのか ─ Codexの“責任範囲”
ここが一番気になるところだろう。
「すごいのは分かった。でも、どこまで任せていいのか？」
結論はシンプルだ。
“手足としては優秀、頭としてはまだ危ない”
だから、設計を任せるのではなく「実装を回させる」のが正解になる。
まず、安心して任せられる領域。
任せていい仕事
- 小規模な機能追加
- バグ修正（再現条件が明確なもの）
- リファクタリング（範囲限定）
- ファイル整理・構成整理
- テストコードの生成
このあたりは、かなり安定している。
むしろ人間より速い。
理由は単純で、
- スコープが限定されている
- 正解の形がある程度決まっている
からだ。
逆に、危ない領域。
任せると事故る仕事
- 仕様が曖昧な開発
- ビジネスロジックの設計
- セキュリティ絡み（認証・権限）
- 大規模な構造変更
- 外部サービスとの複雑な連携
ここはまだ信用できない。
なぜか。
Codexは“それっぽく正しい”コードを出すが、
“本当に正しいか”の責任を取れないからだ。
実際の挙動としても、
- 一見正しそうに見えるが微妙にズレる
- 前提を勝手に補完する
- エッジケースを落とす
こういう“現場で一番困るズレ”をやる。
つまり、役割はこうなる。
設計：人間
実装：Codex
検証：人間
この分業が現実的なライン。
ここで重要なのは、「どこまで任せるか」じゃない。
“どこから回収するか”だ。
Codexは確実に仕事を進める。
ただし、責任は持たない。
だから、
- 任せる
- 進ませる
- 途中で止める
- 人間が判断する
このループを回すのが正解になる。
この構図、よく見ると分かる。
完全自動化じゃない。半自動化でもない。
“委任型作業”だ。
ここまで来ると、見え方が変わる。
Codexはツールではない。
かといって、完全なエージェントでもない。
“制御可能な作業者”
この表現が一番しっくりくる。
なぜここまでできるのか ─ Codexの動作原理
ここまでの挙動を見ると、こう思うはずだ。
「これ、本当にただのLLMか？」
まず前提として、Codexの“頭脳”はLLMだ。
コード生成も、判断も、基本は言語モデルの延長にある。
だが、それだけではこの動きは説明できない。
決定的に違うのは、ここだ。
“環境と接続されている”
従来のAIはこうだった。
- 入力を受ける
- テキストを生成する
- 終わり
完全に“箱の中”で完結していた。
Codexは違う。
- ファイルを読む
- ディレクトリを探索する
- コードを編集する
- 実行する
- 結果を見て再判断する
つまり、
「外の世界に手を出している」
（内部的には、ファイル操作・実行環境・状態管理を統合したエージェント的な構成になっている）
ここで一気に性質が変わる。
テキスト生成から、“行動”になる。
さらに重要なのがもう一つ。
状態を持つこと
普通のチャットAIは、その場の会話しか見ていない。
だがCodexは、
- 今どのファイルを見たか
- 何を変更したか
- どこでエラーが出たか
こういった“作業の流れ”を前提に動く。
これによって何が起きるか。
一発回答ではなく、プロセス型になる
- 仮説を立てる
- 試す
- 失敗する
- 修正する
このループが回る。
ここまで来ると、見えてくるはずだ。
これは単なるAIではない。
「LLM + ツール + 状態管理」
この組み合わせで動いている。
そして、これが意味することはシンプルだ。
能力の本体は“賢さ”ではない。
“回せること”だ。
賢いだけのAIは、答えを出して終わる。
回せるAIは、仕事を終わらせる。
Codexが実務に踏み込める理由はここにある。
開発はどう変わるのか ─ “書く仕事”から“回す仕事”へ
Codexを触ると、一番最初に崩れる前提がある。
「エンジニアはコードを書く仕事」
これ、もう違う。
実際の作業を振り返ると分かる。
自分で書いていた時間よりも、
- 指示を出す
- 挙動を確認する
- 修正ポイントを判断する
この時間の方が長くなる。
つまり、何が起きているか。
“キーボードを叩く時間”が価値じゃなくなる
代わりに重要になるのはこれだ。
- 何をやらせるか決める力
- どこが間違っているか見抜く力
- どこで止めるか判断する力
これ、よく見ると職種が変わっている。
プログラマーではなく、
“作業ディレクター”に近い
さらに変化はもう一段ある。
従来の開発はこうだった。
- 設計
- 実装
- テスト
- 修正
これを人間が順番にやる。
Codexが入るとこうなる。
- 指示
- 実行（Codex）
- 検証（人間）
- 再実行（Codex）
ループが高速化する。
しかも、疲れない作業者が回し続ける。
ここで決定的な差が出る。
開発速度じゃない。
試行回数だ。
これまで1回しか試せなかったものが、
10回、20回と回せるようになる。
この差は、そのまま品質に直結する。
だから、これからの開発で問われるのは、
「どれだけ書けるか」じゃない。
「どれだけ回せるか」
そして、もう一つ現実的な話をしておく。
この変化、全員に優しいわけじゃない。
- 手を動かすだけの人 → 仕事が減る
- 判断できる人 → 価値が上がる
かなり露骨に分かれる。
ただし逆に言えば、今この段階で触っている人間は全員有利だ。
まだ誰も正解を持っていないからだ。
Codexは未来の話じゃない。
すでに“働き方を変え始めているツール”だ。
まとめ ─ Codexは「コード生成AI」の延長ではない
ここまで見てきた通り、Codexは単なる進化版じゃない。
コードを書くだけのAIなら、すでに飽和している。
いくら精度が上がっても、それは“便利な補助ツール”の域を出ない。
だが、Codexはそこを越えてきた。
- コードを読む
- 環境を理解する
- 修正する
- 実行する
- 失敗して、やり直す
この一連の流れを自分で回す。
ここにあるのは「生成」ではない。
“作業”だ。
そして、この違いが意味するものは大きい。
コード生成AIは「速くする」ツールだった。
Codexは「任せる」ツールになっている。
もちろん、まだ万能ではない。
判断は甘いし、責任も取らない。
放置すれば普通に間違える。
それでも、
- 指示すれば動く
- 試行を回す
- 手を動かし続ける
この時点で、すでに実務の一部を代替している。
ここまで来ると、見方は変わる。
Codexは「AIがコードを書く時代」の話ではない。
「AIに仕事を渡す時代」の入口だ。
この差に気づくかどうかで、使い方はまったく変わる。
触ってみて感じたのはシンプルだった。
これは便利かどうかの話じゃない。
“仕事のやり方を変えるかどうか”の話だ。
これは「AIが何をできるか」ではなく、
「人間が何を手放すか」の問題になっている。
こういう“実際に使えるAIツール”を探している方は、お問い合わせからどうぞ。
