CodexやAIコーディングエージェントという言葉を聞くと、多くの人はまずこう考えるかもしれません。
「これは開発者向けのツールだ」と。
私も以前はそう思っていました。
私の仕事はプロジェクトコーディネーターです。日々の多くは、要件、スケジュール、タスク、テストケース、ドキュメント、進捗管理、そして事業、プロダクト、デザイン、開発の間をつなぐことに使っています。プロダクトを作るために、直接コードを書く立場ではありません。
そのため、Codexを使い始めたときの目的は、AIを使って開発者になることではありませんでした。知りたかったのは、もっと実務的なことです。
プロジェクトコーディネーターの仕事で、AIエージェントを使って手作業を減らし、より効率的に働けるのか。
しばらく使ってみた今、私の答えは「はい」です。
一番意外だったのは、私の仕事におけるCodexの価値が、コードを書く能力そのものにあるわけではなかったことです。むしろ、文脈を読み取り、複数の情報源を扱い、結果が完成するまで一連の作業を進められる点に価値がありました。
つまり、私はCodexに答えを聞いているだけではありません。仕事の一部を任せて実行してもらっているのです。
チャットボットから実行レイヤーへ
以前AIを使うとき、私の流れはとても一般的でした。質問を投げる、文章を受け取る、それをドキュメントにコピーする、構成を整える、そして残りの作業を自分で進める。
Codexを使うようになって、この流れが少しずつ変わりました。
たとえば、「良いチケットには何を書くべきか？」と聞く代わりに、要件、ガイドライン、期待する形式を渡し、Codexに内容を分析させ、チケットを書かせ、必要な形に整えてもらうことができます。
Codexを簡単なイメージで表すなら、チームの若手メンバーに近い存在です。具体的な作業を渡し、文脈とルールを共有し、そのうえで実行してもらいます。
もちろん、結果を確認し、最終的な成果物に責任を持つのは私です。ただ、自分で細かい手順をすべて行う代わりに、より重要な3つの問いに集中できます。何をするべきか、どのロジックに従うべきか、最終結果はどうあるべきか。
これはAI導入にも関係します。Linnoedgeの社員がAIを使わない理由は「恐れ」ではなく「時間」だったという記事でも触れているように、AIが本当に効き始めるのは、ツールを配った時点ではありません。実際の業務フローに組み込まれたときです。
Planeでのチケット入力から結果レビューへ
私にとって最も実用的な使い方のひとつは、Planeでのタスク管理です。
議論が終わったあと、または要件が合意されたあと、私はタイトル、説明、受け入れ条件、優先度、ラベル、担当者、他タスクとの関連、参照情報を含めてチケットを作成する必要があります。
1件や2件であれば大きな問題ではありません。しかし、ひとつの機能が多くの小さなタスクに分かれることがあります。複数の機能が同時に進むと、一見単純な「タスクを登録する」作業が、かなりの時間を占めるようになります。
この作業には小さな矛盾があります。繰り返しが多い一方で、正確さも求められるのです。
今の業務フローでは、要件とガイドラインをCodexに渡し、内容を分析し、タスクに分解し、決められた形式でチケット案を作成し、次に必要な作業を準備してもらえます。私はひとつずつチケットを開いてコピーし、形式を整える作業から、まとめて出てきた結果を確認する作業へ移れます。
タスク数が多い場合、節約できる時間はかなり明確です。このあたりから、私はCodexを業務フローの中の実行レイヤーとして見るようになりました。質問に答えてもらう道具、という感覚は薄れました。
ただし、良いチケットは良い要件から始まります。Linnoedgeでは以前、複雑なコードよりも曖昧な要件のほうが開発を難しくすることについて書いています。AIに作業準備を任せるときほど、この点は重要になります。
新しく作るより、一貫性を保つほうが効いた
プロダクト開発の中で、要件が止まったままでいることはほとんどありません。
事業側がロジックを変更することがあります。デザイナーがフローを更新することがあります。開発者が新しい制約に気づくことがあります。QAが、まだ書かれていなかった例外ケースを見つけることもあります。
小さな変更でも、その後には一連の作業が続きます。チケットを修正し、受け入れ条件を更新し、テストケースを調整し、ドキュメントを変更し、関連する内容がまだ一致しているか確認する必要があります。
手作業で行うと、これは長いコピー＆ペーストの流れになりやすいです。関連する成果物が増えるほど、見落としも起きやすくなります。
Codexを使えば、新しいロジックを説明し、関連する内容を確認させ、影響を受ける箇所を洗い出し、修正案を出したり実際に更新したりできます。人間による確認は必要ですが、すべての行を探して直す作業に大半の時間を使う必要はなくなります。
AIは新しい内容を作るだけではありません。すでに存在する内容の一貫性を保つことにも役立ちます。
難しくはないのに、数日かかる作業
テストケースはわかりやすい例です。
アプリ内のフローが変わると、既存のテストケースを多く確認する必要があります。まだ有効なテストケースはどれか、手順を修正すべきものはどれか、期待結果が変わったものはどれか、追加すべき例外ケースはあるか、もう不要になったシナリオはあるか。
ドキュメントも同じです。プロダクトのひとつの変更が、要件定義書、機能仕様書、テストケース、タスク説明、社内ガイドラインに同時に現れることがあります。
以前は、変更範囲が大きい場合、これらすべてを確認して更新するだけで数日かかることもありました。Codexは、その作業をより構造化された流れに変えてくれます。
新しい文脈を確認する → ドキュメントを読む → 影響範囲を特定する → 更新する → 結果を確認する。
違いは、人間が完全に不要になることではありません。何百回もの手作業に消えていた時間を、ロジックの確認に回せるようになったことです。
これはテストでも重要です。Linnoedgeのすべてのテストが通っているのに本番で壊れる理由の記事でも説明しているように、見た目には問題がなさそうでも、本当に確認すべき前提を見落としていることがあります。
生のプロジェクトデータから、判断できる情報へ
レポート作成も、私がCodexを便利だと感じる使い方です。
プロジェクトコーディネーターは、よく次のような質問に答える必要があります。どのタスクが止まっているのか、どの機能が未完了なのか、未解決の不具合はいくつあるのか、期限を過ぎたタスクはどれか、スプリントはどこまで進んでいるのか、各メンバーの作業量は今どうなっているのか。
データ自体はタスク管理システムの中にすでにあるかもしれません。しかし、それを絞り込み、要約し、読みやすいレポートへ変えるには時間がかかります。
Codexは、生のプロジェクトデータから意思決定に使える情報までの距離を短くしてくれます。特定の条件でデータを集め、朝会、スプリントレビュー、プロジェクト報告に使える要約を作るよう依頼できます。
AIは、既存のプロジェクトデータをチームが判断できる情報に変えたときに、本当に役立ちます。
これはスケジュール管理とも近い関係があります。レポートは単なる進捗報告ではありません。期限の前にリスクを見つけるための材料です。良い見積もりとスケジュールへの責任が、開発チームの判断を早めるのと同じです。
開発者への質問の質が上がった
自動化だけでなく、Codexは技術的な問題に近づくときにも役立ちます。
事業側から見ると簡単に見える要件でも、実装時には単純ではないことがあります。たとえば、母子向けアプリで「選択した時間に、ユーザーへ活動のリマインダー通知を送る」という要件があったとします。
この短い一文の裏には、多くの質問があります。ユーザーがタイムゾーンを変更したらどうなるのか。通知許可がオフの場合はどうするのか。通知時刻の前に活動が完了していたらどうするのか。ユーザーがリマインダー時刻を変更した場合はどうするのか。同じアカウントを複数端末で使っている場合はどうなるのか。
以前なら、こうした点に気づくために早い段階で開発者に質問していたかもしれません。今は、Codexを使って先に小さな調査を行えます。要件を分析し、依存関係を探し、例外ケースを洗い出し、確認すべき質問を準備するのです。
それによって、私がコードレビューできる人になるわけではありません。ただ、問題をより深く理解し、開発者と話すときの質問の質を上げることができます。
このコミュニケーションの質はとても重要です。LinnoedgeのITにおけるコミュニケーションミスの記事でも、曖昧な報告や質問がチーム全体を遅くし、具体的な文脈があるほど全員が動きやすくなることを紹介しています。
変わったのは役割ではなく、働き方
自分の経験を通じて、Codexがプロジェクトコーディネーターを開発者に変えるとは思っていません。AIの目的が、チームの中の役割を完全に置き換えることだとも思いません。
最も大きく変わったのは、仕事の分け方です。
以前は、私の多くの時間が手作業に使われていました。チケットを作成・修正する、テストケースを更新する、ドキュメントを直す、レポートをまとめる、複数の場所にあるデータを確認する。
今は、その中の多くをAIに先に準備してもらえます。私の役割は少しずつ、次の方向へ移っています。
依頼を定義する → ルールを設定する → 文脈を渡す → 成果物を確認する → 判断する。
だからこそ、私はCodexをチームの若手メンバーに近いものとして捉えています。曖昧な依頼をすれば、結果もずれるかもしれません。十分な文脈、明確なルール、具体的な成果物を渡せば、かなりの量の仕事を進められます。
プロジェクトコーディネーターは、Codexを使うために必ずしもコードを知っている必要はありません。ただ、システムのロジック、依存関係、業務フロー、そしてAIエージェントとの働き方を理解しているほど、より大きな利点を得られると思います。
重要なスキルは、単に「AIを使えること」だけではありません。AIに仕事を任せる力です。問題を分解し、十分な文脈を渡し、ルールを作り、結果を確認し、自動化できる部分と人間の判断が必要な部分を見分ける力です。
私にとってCodexが役立つのは、開発者の仕事を代わりにするからではありません。繰り返し作業を減らし、より多くの情報を扱いやすくし、本当に調整、思考、意思決定が必要な部分に時間を使えるようにしてくれるからです。
AIは私たちの職種名を変えるとは限りません。しかし、毎日の働き方は大きく変えられます。
チームの実務にAIエージェントを組み込みたい方へ
リノエッジはベトナム・ホーチミンのソフトウェア開発会社です。この記事のCodexの使い方は、社内のコーディネーターが実際にやっていることで、同じ組み込みをお客様のチームの業務フローでも支援しています。自社ならどこから始められるか、一度話してみませんか。
ソフトウェアに恋したソフトガール。ITコーディネーター見習いとして、自身の試行錯誤から学んだ教訓をシンプルなヒントに変え、仕事をもっとアクセスしやすく・楽しくすることを目指しています。
非エンジニアの立場でAIエージェントを実務に取り入れる考え方は、企業向けAI研修でも扱っています。