Codexは「コードを書くAI」ではない。SEの開発・調査・テスト・事務処理まで変える“実務エージェント”だ

Posted at 2026-04-24

はじめに：AIを使うSEと、AI時代に埋もれるSEの差はどこで生まれるのか

株式会社エスプリフォートは、
「ITの力でお客様のビジネスを支え、笑顔と価値を創造する」ことを大切にしているシステム開発会社です。

私たちは、単にシステムを作るだけではなく、
顧客価値をどう生み出すか
仲間とどう成果を出すか
技術をどう“仕事の価値”に変えるか
を本気で考えています。

今、システムエンジニアの仕事は大きく変わり始めています。

その一つが、Codexです。

Codexと聞くと、まだ「AIがコードを書いてくれるツール」と思っている人も多いかもしれません。
しかし、最新版のCodexはそのレベルではありません。

今のCodexは、コードを書くAIではなく、
開発・調査・レビュー・テスト・ドキュメント・事務処理まで一緒に進められる実務エージェントです。

OpenAI公式では、Codex CLIはローカル端末で動かせるコーディングエージェントであり、選択したディレクトリ内のコードを読んだり、変更したり、コマンドを実行したりできると説明されています。(OpenAI Developers)

つまり、Codexはもう「質問に答えるAI」ではありません。
あなたのPC上で、実際のファイルを読み、必要な処理を行い、成果物を作る存在になっています。

ローカルPCで事務処理もできる

Codex CLIはローカル端末で実行でき、選択したディレクトリ内のファイルを読んだり、編集したり、コマンドを実行したりできます。(OpenAI Developers)

これが何を意味するかというと、
ローカルPC上の作業フォルダにあるファイルを対象に、実務処理を任せられるということです。

たとえば、以下のような作業です。

CSV加工

このフォルダにあるCSVを読み込んで、
以下の条件で整形してください。

・空欄の行を削除
・日付形式を yyyy-mm-dd に統一
・重複データを削除
・結果を output.csv に保存
・処理内容を summary.md にまとめる

テストデータ作成

このDB定義をもとに、
会員登録機能のテストデータをCSVで作成してください。

正常系、異常系、境界値を含めてください。
メールアドレス、電話番号、生年月日、住所のパターンも分けてください。

JSON整形

このJSONファイルを読み込んで、
キーの並びを統一し、不要な項目を削除してください。
変更前後の差分も説明してください。

SQL作成

このテーブル定義をもとに、
テスト用INSERT文を100件分作成してください。
正常系、異常系、境界値、NULLパターンを含めてください。

フォルダ内ファイルの整理

このフォルダ内のファイル名を確認し、
命名規則に合っていないファイルを一覧化してください。
修正案も出してください。

こういう作業は、これまで地味に時間がかかっていました。

Excelを開く。
CSVを確認する。
置換する。
スクリプトを書く。
チェックする。
また修正する。

Codexを使うと、これらを自然言語で指示して、必要に応じてスクリプトを書かせて、実行して、結果を確認するところまで進められます。

誤字脱字チェック・表記ゆれチェックにも使える

Codexはコードだけでなく、ドキュメントにも強いです。
GPT-5.5はCodexでナレッジワーク成果物にも有用とされており、仕様書、README、手順書、記事、社内資料などのチェックにも使いやすくなっています。(OpenAI Developers)

たとえば、以下のように使えます。

このREADME.mdをチェックしてください。

観点は以下です。
・誤字脱字
・表記ゆれ
・不自然な日本語
・説明不足
・手順の抜け漏れ
・初心者が読んで迷いそうな箇所

修正案を出してください。

仕様書ならこうです。

この仕様書をレビューしてください。

観点は以下です。
・曖昧な表現
・実装者が判断に迷う箇所
・テスト観点が不足しそうな箇所
・例外処理の記載漏れ
・画面項目とDB項目の不整合

Qiita記事ならこうです。

このQiita記事をレビューしてください。

観点は以下です。
・エンジニアに刺さる導入になっているか
・技術的に誤解を招く表現がないか
・冗長な表現がないか
・見出しの流れが自然か
・最後まで読みたくなる構成か

SEの仕事では、文章のわかりやすさや仕様の詰まり具合などがその後の工程や作業に直結して影響を及ぼします。

仕様書が曖昧なら、実装がブレます。
READMEが分かりづらければ、チームの立ち上がりが遅れます。
手順書に抜けがあれば、運用ミスが起きます。
テスト観点が弱ければ、障害につながります。

Codexは、こうした開発周辺の品質も底上げしてくれます。

画面確認・UIテストにも使える

最新版Codexでは、Codexアプリ内のブラウザを操作して、ローカル開発サーバーやファイルベースのページを開き、画面の状態を確認したり、表示バグを再現したり、修正を検証したりできるようになっています。(OpenAI Developers)

Codexのin-app browserは、ローカル開発サーバーやファイルベースのプレビュー、ログイン不要の公開ページに使え、Codexがクリック、入力、表示状態の確認、スクリーンショット取得、修正確認を行う用途で使えると説明されています。(OpenAI Developers)

たとえば、こう依頼できます。

http://localhost:3000/settings をブラウザで開いて、
レイアウト崩れを確認してください。

崩れている箇所を特定し、
最小限のCSS修正で直してください。
修正後にもう一度ブラウザで確認してください。

これはWeb系SEにとってかなり協力なツールです。

今までは、

自分で画面を開く
崩れを確認する
コードを見る
修正する
また画面を見る
また直す

という流れでした。

Codexを使うと、この反復をかなり短縮できます。

もちろん、最終確認は人間が行うべきです。
しかし、初期調査や修正候補の作成、軽微なレイアウト修正にはかなり役立ちます。

Codexアプリで複数作業を並行できる

Codexアプリは、複数のCodexスレッドを並行して動かし、プロジェクトごとに作業を管理できるデスクトップ体験として提供されています。OpenAI公式では、Codexアプリは並列スレッド、worktree、オートメーション、Git機能を備えた開発用コマンドセンターとして説明されています。(OpenAI Developers)

たとえば、1つのプロジェクトで次のように並行できます。

スレッドA：バグ調査
スレッドB：テストコード作成
スレッドC：README修正
スレッドD：リファクタリング案作成
スレッドE：テストデータ生成

Codexアプリのworktree機能では、同じプロジェクト内で複数の独立した作業を走らせ、互いに干渉しにくくできます。Gitリポジトリでは専用のworktreeを使って、未完成のローカル作業と競合しにくい形でタスクを分離できます。(OpenAI Developers)

これは、実務ではかなり便利です。

SEの仕事は、1つの作業だけをしているわけではありません。

障害調査をしながら、
レビューをしながら、
次の機能の設計をしながら、
資料も直す。

そういう状況は普通にあります。

Codexアプリを使えば、作業を分けて並行実行し、差分を確認しながら進められます。

プラグインでCodexはさらに広がる

最新版Codexで重要なのが、プラグインです。

Codexのプラグインは、スキル、アプリ連携、MCPサーバーをまとめて、再利用可能なワークフローとして使える仕組みです。公式ドキュメントでは、Gmail、Google Drive、Slackのプラグイン例が紹介されており、Gmailを読んで管理する、Google Drive上のDocs・Sheets・Slidesを扱う、Slackチャンネルを要約したり返信案を作ったりする用途が示されています。(OpenAI Developers)

つまり、Codexはローカルのコードだけでなく、
普段の仕事で使っているツールにも広がっていくということです。

たとえば、将来的な実務イメージとしてはこうです。

Google Drive連携

Google Driveから最新の仕様書を確認し、
今回の実装差分と矛盾がないかチェックしてください。
不整合があれば一覧化してください。

Slack連携

今日のプロジェクトチャンネルを要約し、
自分が対応すべきタスク、確認が必要な質問、リスクを整理してください。

Gmail連携

今日届いた未読メールの中から、
プロジェクト対応が必要なものを抽出し、
返信案を作成してください。

Google Sheets連携

テストケース一覧を確認し、
今回の修正に対して不足している観点を追加してください。

これができるようになると、SEの仕事はさらに変わります。

コードだけでなく、
仕様、会話、資料、チケット、テスト、レビューがつながるからです。

スキルで“会社のやり方”をCodexに覚えさせられる

さらに重要なのが、スキルです。

Codexのスキルは、特定の作業のための再利用可能な手順・参考資料・補助スクリプトをまとめたものです。公式では、スキルはSKILL.mdと任意のスクリプト、参考資料、テンプレートなどを含むディレクトリとして説明されています。(OpenAI Developers)

これが非常に大きいです。

なぜなら、スキルを使えば、Codexに
自社の標準手順
チームのレビュー観点
プロジェクト固有の作法
を持たせられるからです。

たとえば、以下のようなスキルが考えられます。

日本語校正スキル

誤字脱字を見る
表記ゆれを見る
採用記事として刺さるか確認する
エスプリフォートらしい温度感に整える
読み手が行動したくなる流れにする

テストデータ生成スキル

正常系
異常系
境界値
NULL
桁数超過
不正文字
日付不整合
重複データ
権限別データ

を自動で作る。

レビュー観点スキル

仕様漏れ
例外処理
セキュリティ
パフォーマンス
保守性
命名
テスト不足
影響範囲

を毎回同じ品質で確認する。

Qiita記事作成スキル

強い導入
実務例
コード例
注意点
読者が明日から使えるプロンプト
最後の採用PR

まで、記事の型として持たせる。

障害調査スキル

ログ確認
再現条件
原因候補
暫定対応
恒久対応
影響範囲
再発防止策

を整理する。

これにより、Codexは単なる汎用AIではなく、
チームの仕事の型を持った実務パートナーになります。

MCPで社内ツールや外部ツールともつながる

CodexはMCPにも対応しています。

MCP、Model Context Protocolは、Codexを外部ツールや共有情報に接続するための仕組みです。OpenAI公式では、MCPによりCodexへサードパーティドキュメントやブラウザ、Figmaなどの開発ツールへのアクセスを与えられると説明されています。(OpenAI Developers)

また、CodexはCLIとIDE拡張の両方でMCPサーバーをサポートし、STDIOサーバーやHTTPサーバー、OAuth認証などにも対応しています。(OpenAI Developers)

MCPを使うと、たとえば以下のような可能性があります。

GitHubのIssueを読ませる
LinearやBacklogのチケットと連携する
Figmaのデザイン情報を見る
社内ドキュメント検索とつなぐ
独自の業務DBやナレッジベースとつなぐ
テスト管理ツールとつなぐ
ログ基盤とつなぐ

スキルが「仕事のやり方」だとすれば、
MCPは「仕事に必要な情報や道具への接続」です。

そして、OpenAI公式でも、スキルとMCPを組み合わせることで、スキルがワークフローを定義し、MCPが外部ツールやシステムに接続する形になると説明されています。(OpenAI Developers)

これはかなり重要です。

Codexは、ただコードを書く存在から、
チームの開発業務全体をつなぐ存在になっていくということです。

実務で使えるCodexプロンプト集

1. 事務処理

このフォルダ内のExcel/CSVファイルを確認し、
データの重複、空欄、形式不一致を洗い出してください。

修正案を出し、
可能であれば修正版ファイルも作成してください。

2. テストデータ作成

この画面仕様書とDB定義をもとに、
テストデータを作成してください。

以下を含めてください。
・正常系
・異常系
・境界値
・必須項目未入力
・桁数超過
・日付不整合
・重複登録
・権限別パターン

CSV形式で出力してください。

3. 誤字脱字チェック

このMarkdownファイルを校正してください。

観点は以下です。
・誤字脱字
・表記ゆれ
・不自然な日本語
・説明不足
・読みづらい文
・Qiita記事として弱い見出し

修正案と、修正後の全文を出してください。

4. 仕様書レビュー

この仕様書をレビューしてください。

実装者目線で、
曖昧な箇所、確認が必要な箇所、テスト観点が不足しそうな箇所を一覧化してください。

5. 既存コード調査

このリポジトリで、注文確定処理がどこに実装されているか調査してください。

処理の流れ、関連ファイル、DB更新、外部API、例外処理、テストの有無を整理してください。

6. バグ調査

このエラーログをもとに、原因候補を優先度順に整理してください。

それぞれについて、
・確認方法
・修正方針
・影響範囲
・追加すべきテスト
を出してください。

7. レビュー前チェック

今回の差分をレビューしてください。

観点は以下です。
・仕様漏れ
・例外処理
・nullチェック
・パフォーマンス
・セキュリティ
・既存機能への影響
・テスト不足
・可読性
・命名

8. PR本文作成

今回の差分をもとに、PR本文を作成してください。

以下を含めてください。
・変更概要
・背景
・変更内容
・動作確認
・影響範囲
・レビューしてほしい観点

9. 画面確認

ローカルの開発サーバーを起動し、
http://localhost:3000 をブラウザで確認してください。

表示崩れ、コンソールエラー、操作できない箇所がないか確認し、
問題があれば修正してください。

10. チーム用スキル作成

このプロジェクト用に、レビュー観点スキルを作成してください。

観点は以下です。
・Javaのコーディング規約
・SQLの性能
・例外処理
・ログ出力
・テスト観点
・既存影響
・セキュリティ

Codexを使ううえで絶対に忘れてはいけないこと

Codexは強力です。
しかし、Codexに丸投げすればいいわけではありません。

大切なのは、
何を成果とするかを人間が決めることです。

悪い使い方はこうです。

いい感じに直して。

良い使い方はこうです。

この処理は注文確定時の在庫引当処理です。
同時実行時に在庫数がマイナスになる可能性があります。

以下の条件で修正案を出してください。
・既存仕様を大きく変えない
・DBトランザクションを考慮する
・テストコードを追加する
・影響範囲を説明する
・本番運用時の注意点も出す

AIを使う力とは、
AIに雑に頼む力ではありません。

目的、制約、期待成果、判断基準を言語化する力です。

ここが弱い人は、Codexを使っても成果は弱いです。
逆に、ここが強い人は、Codexを使って圧倒的に仕事を進められます。

これからのSEに必要なのは「AIに詳しいこと」ではない

これからのSEに必要なのは、
AIのニュースを追うことだけではありません。

本当に必要なのは、
AIを使って成果を変える力です。

たとえば、

調査時間を半分にする
テストデータ作成を自動化する
レビュー品質を上げる
仕様書の曖昧さを減らす
誤字脱字を減らす
手順書を分かりやすくする
バグ調査を速くする
画面確認を効率化する
若手の立ち上がりを早くする
チーム全体の生産性を上げる

これができて初めて、AIを使っている意味があります。

AIを触っているだけでは意味がありません。
AIで成果を出してこそ、価値があります。

CodexはSEを楽にする道具ではない。SEを価値ある仕事の集中できるようにする道具だ

Codexを使えば、確かに作業は楽になります。

でも、本質はそこではありません。

Codexの本当の価値は、
SEがより価値ある仕事に集中できるようになることです。

単純作業に追われるのではなく、
顧客価値を考える。

テストデータ作成に時間を奪われるのではなく、
テスト設計に集中する。

誤字脱字修正に追われるのではなく、
伝わる仕様書を作る。

コードを直すだけで終わるのではなく、
なぜその修正が必要なのかを考える。

AI時代のSEは、
「コードを書く人」から、
価値を設計し、AIを使って成果を実現する人へ変わっていきます。

最後に

エスプリフォートは、
単にシステムを作る会社ではありません。

私たちは、
ITの力でお客様のビジネスを支え、笑顔と価値を創造する会社です。

そして、AIのような先進技術も、ただ流行として使うのではなく、
顧客価値を生み出すため
仲間の成果を高めるため
もっと面白い仕事をするため
に活用していきたいと考えています。

ただ実装するだけではなく、
調査し、考え、改善し、検証し、伝え、成果に変える。

そんなSEが、これからの時代に必要とされます。

エスプリフォートでは、
AIを活用しながら、顧客価値を生み出し、仲間と一緒に成長し、
「この会社で働いていてよかった」と思える未来をつくっていきたいと考えています。

AI時代に、ただ流される側ではなく、
AIを使って価値を創る側へ。

エスプリフォートで、
“AI時代の価値創造エンジニア”として、
一緒に面白い未来をつくっていきませんか。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up