マネージャーをしています。育休を取り、2026年2月に復帰しました。育休中はがっつりパパになっていてITどころじゃなかったので一瞬浦島太郎になりかけましたが、AI界隈は流れが早すぎて多少期間が空いても大体みんな同じところをキャッチアップしているという点に助けられました。
復帰後、AI開発ツールを集中的に触り直しました。育休前からAIは業務に使っていましたが、復帰して触り直したとき、使い道の重心が変わったと感じました。以前は業務ごとに異なるAIツールをバラバラに使い分けていたのが、今は1つのCLIツールにプロジェクト全体の文脈を与えて、マネージャーとしての仕事を回しています。
本記事ではこの変化を、実践をもとに整理します。
なお、本記事ではおすすめも兼ねてClaude Codeを中心に書きますが、同じアプローチはOpenAIのCodex CLI（設定ファイル: AGENTS.md）やGoogleのGemini CLI（同: GEMINI.md）でも再現できます。いずれも「設定ファイルにAIの振る舞いを定義し、プロジェクト全体を文脈として与える」という同じ思想で設計されています。お使いのツールに読み替えてください。
育休前もAIは日常的に使っていました。ただし、業務ごとにツールを使い分ける形でした。
他にも色々ありますが、それぞれのツールはしっかりと役割を果たしていました。ただ、振り返ると当時のAIは基本的に「相談相手」でした。こちらが情報を渡して質問すると、整理された回答やドラフトを返してくれる。優秀なアドバイザーです。ですが、最終的なアクション——TODOリストを集めてくる、ファイルを作る、複数の情報を突き合わせる——は自分でやっていました。
もう一つの限界は、タスクが終わったらそこで完結することでした。ChatGPTで壁打ちした内容を、Claude Codeが知っているわけではない。Geminiが文字起こしした会議メモを、ChatGPTが読んでいるわけでもない。プロジェクト全体の文脈——複数の施策の関連性、会議で決まったことと未着手タスクの紐づけ——こうした情報をつなぐのは、全て自分の頭の中でやっていました。
Claude Code自体はリリース当初からエージェント型のツールでした。ファイルを読み書きし、コマンドを実行する能力は最初からあります。ただ、復帰して触り直すと、エージェントとしての実用性が明確に上がっていました。
背景にはモデルの世代交代があります。Claude Codeの裏で動くAIモデルは、Sonnet 4.5（2025年9月）、Opus 4.5（同11月）と立て続けにアップデートされ、復帰直後の2026年2月にはOpus 4.6とOpenAIのGPT-5.3-Codexが同日にリリースされました。各社がエージェント型AIの性能を競い合っている時期に、たまたま復帰したことになります。体感としては、育休前は「指示したことはやるが、たまに的外れなことをする」だったのが、復帰後は「こちらの意図を汲んで、先回りして動く」に変わっていました。ツール側も、並行作業を担うサブエージェントやカスタムコマンド（スキル）が追加され、できることの幅が広がりました。
何が変わったのかを整理すると、「複雑なワークフローを定義できるようになった」ことと「定義したワークフローを最後まで辿れるようになった」ことの掛け算です。
1つ目は、カスタムコマンドの仕組みが拡張され、複雑な作業手順を実用的に定義できるようになったこと。 Markdownで作業手順を書いてカスタムコマンドとして呼び出す仕組み自体は以前からありましたが、複数ファイルでの構成やサブエージェントとの連携など、より複雑なワークフローを組めるように拡張されました。たとえば復帰後に作った /create-issue というコマンドは、「要望のテキストを受け取る → コードベースを自律的に探索してデータフローを追跡する → 問題箇所を特定する → 修正方針を策定する → 構造化されたGitHub Issueを作成する」という一連の流れを定義したものです。一言コマンドを打つだけで、10ステップ近い作業が自律的に進みます。
2つ目は、モデルの精度が上がり、その長い手順を最後まで正確に辿れるようになったこと。 ワークフローを定義する仕組みがあっても、途中で的外れなファイルを拾ったり、手順を飛ばしたりしては実用になりません。過去のモデルなら途中でコケていたであろう複雑な探索——ルーティング定義からコントローラー、サービス、モデルへとデータフローを追跡し、関連するバリデーションやテストまで確認する——が、復帰後は安定して動くようになっていました。実際、復帰後にヘルプで入った初見のコードベース（金融系、為替の計算ロジック）でも、自作の /create-issue スキルでコードベースを探索させると的確に問題箇所を拾ってきました。扱えるコンテキストの上限も、育休前に使っていたモデルの200Kトークンから、復帰後に出たOpus 4.6では最大1Mトークンに広がっており、より多くのファイルを一度に見渡せるようになっています。
この2つは掛け算です。ワークフローの定義だけあってもモデルが辿れなければ意味がなく、モデルが賢くなっても定義がなければ毎回プロンプトを手打ちすることになる。両方が揃ったことで、「設定ファイルとカスタムコマンドでAIの振る舞いを組み立て、チーム全体で再利用する」という使い方が現実的になりました。
復帰後に試したことのうち、マネジメント寄りのものを紹介します。
復帰してすぐ、複数の施策が同時に走っている状態に入りました。各施策のTODO、会議の決定事項、年間計画の進捗。情報はMarkdownファイルとして散在しています。育休前なら毎朝ファイルを巡回して、頭の中で優先順位を組み立てていたところです。
そこで /next-action というスキルを作りました。
# /next-action スキル（抜粋）
1. プロジェクト全体からTODOファイルを検索
2. 直近1週間の会議メモからアクションアイテムを抽出
3. 年間計画の当月マイルストーンと照合
4. 優先度を判断し、上位5件のアクションを提案 ターミナルで /next-action と打てば、散在するMarkdownファイルを横断探索し、優先度付きのアクションリストが返ってきます。既存のプロジェクト管理ツールを別途導入しなくても、Markdownファイル群とCLIだけで最低限の情報集約が成立します。
復帰後に最も時間を使ったのが、新卒研修の設計でした。
9営業日のバックエンド研修を3フェーズで組みました。前半は手を動かして基礎を身体に入れ、中盤からAIとの協業を導入し、後半でIssueベースの疑似実務を行います。設計上の要点は「テストを書ける人間だけがAIに仕事を任せられる」ということを体験させることです。
カリキュラムの骨格を決めるのは人間の仕事です。ただし、骨格が固まった後の工程が育休前とは変わっていました。研修の目的、フェーズ構成、各Dayのテーマ、演習チケットの仕様、受講者に使わせるプロンプト集まで、CLAUDE.mdに仕様として定義しました。Claude Codeはその仕様に従い、9日分の教材・チェックリスト・演習チケット・テスト付きの雛形アプリケーションを生成しました。
さらにチーム演習用のベースシステムも、RFPを書いてClaude Codeに構築させています。フロントエンドからバックエンド、テスト157件、E2Eシナリオ42件を含むWebアプリケーションの完成品です。
育休前のチャットAIでも「カリキュラムの壁打ち」はできました。しかし「仕様を渡して研修リポジトリ一式を生成する」のは、コードベースを横断的に扱えるエージェントでなければできません。
マネージャーとして考えなければならないのは、自分の生産性だけでなくチーム全体の底上げです。「各自が好きに使う」状態ではAIツールの効果がばらつきます。
復帰直後、リリース前の追い込みで人手が足りなくなっていた金融系プロジェクトにヘルプで入りました。初見のコードベースです。ここでの立ち上がり方が、標準化の重要性を実感する経験になりました。
まずやったのはテスト基盤の強化です。AIに実装を任せるなら、テストが通る状態を維持していないと壊れたかどうか検証できません。スキップされていたテストを復元し、フロントエンド側にもテスト基盤を追加して、バックエンド・フロントエンドの両方でテスト駆動の土台を固めました。
土台ができた上で、プロジェクト共通のカスタムコマンド群を整備しました。Issue作成（/create-issue）、TDD実装（/implement-issue）、PR作成（/create-pr）、コードレビュー（/code-review）といった開発ワークフローをテンプレート化し、中央リポジトリから各プロジェクトに同期する仕組みを作りました。もともとこのプロジェクトではAIベースのコードレビューサービスを使っていましたが、全社展開のコストを考慮し、既に契約済みのClaude Codeのカスタムコマンドで代替する判断をしました。
並行して、5段階のClaude Codeハンズオンチュートリアルも整備しました。テストの価値を理解するところから始めて、段階的にAI協業の比率を上げていく設計です。
個々のコマンドはエンジニアが使う開発効率化ツールです。ですが「テスト基盤→カスタムコマンド」の順序で何を標準化するか、コストを見てどのツールで代替するかを設計するのはマネジメントの仕事であり、自分で使ってみないとこの順序は見えてきませんでした。
急速に整備が進んだもう一つの変化がMCP（Model Context Protocol）です。AIが外部サービスにアクセスするための標準仕様で、Anthropicが発表した後、OpenAIやGoogleも採用し、Linux Foundation傘下で標準化が進んでいます。
復帰後、Slack MCPでのAIから人間への指示出し、draw.io MCPでのインフラ構成図生成、Playwright MCPでのE2Eテスト実施など、他にもいくつかのMCPサーバーを試作しました。正直に言えばまだ実験段階で、業務に定着したとは言えません。ただ方向性は見えました。MCPによる「散在するドメイン特化情報の集約」がローカルファイルからクラウドサービスに広がり、マネジメントツールとしてのポテンシャルに大きく寄与させられると感じています。
ここまでは「うまくいったこと」の話です。次は「うまくいかなかったこと」を書きます。
復帰後、「AIにプロジェクトマネジメントを全面的に任せられるか？」を検証するプロジェクトを立ち上げました。
コンセプトはこうです。仕事には「ハードタスク」（現実世界のアクションが必要な仕事。顧客ヒアリング、承認取得、環境構築など）と「ソフトタスク」（PC内で完結する仕事。ドキュメント作成、コードレビュー、テスト設計など）がある。ソフトタスクはAI PMが自律的に実行し、ハードタスクはAI PMが人間に指示を出す。人間はAI PMの判断に基づいて現実世界のアクションを実行する——という構想です。
仮想の受託案件RFPを用意し、AI PMがプリセールスから納品まで一気通貫でプロジェクトを進行するシミュレーションを繰り返しました。
結論から言うと、「全任せ」は成立しませんでした。ただし、原因はAIの能力不足ではなく、ガードレールの設計不足でした。
最初に直面した問題がこれでした。プリセールス → 提案 → 契約 → 要件定義 → 設計 → 実装 → テスト → 納品まで全工程をAI PMに主導させると、人間側が「AIは今何をしているのか」を把握できなくなりました。営業交渉の状況、法務判断の進捗、技術選定の根拠——AIが動く範囲が広すぎて、どこに人間の介入が必要なのかが見えません。
AI PMが出す指示に人間が従う——この構図は、AIの判断を人間が検証できなくなった時点で破綻します。
対策として、AI PMのスコープを「要件定義～納品」に絞りました。プリセールスと契約は人間が完了させ、RFPと契約条件をAIに引き渡す形にしました。スコープを限定したことで、人間の介入ポイントが明確になり、この問題は解消しました。
シミュレーション中、AI PMがRFPを読んだ直後に要件定義書のドラフトを作り始めました。顧客ヒアリングを完全に飛ばして、です。
AIは効率を重視します。手順書がなければ「RFPに書いてあるから分かる」と判断して、人間との対話プロセスをスキップします。これは「AIが賢すぎる」のではなく、何をどの順序でやるかの手順書（方法論）が足りなかったのが原因です。
対策として、各フェーズに詳細な作業手順書を用意しました。各ステップを「ソフトタスク（AI実行）」か「ハードタスク（人間に委譲）」に分類し、特に「この工程は人間のアクションが必須であり、完了するまで次に進んではならない」というブロッキングルールを明記しました。手順書を整備するとAI PMの振る舞いは明確に改善し、工程の飛ばしは発生しなくなりました。
ただし、これは裏を返せば手順書のカバレッジが品質を決めるということです。定型的なウォーターフォール工程であれば手順書で十分カバーできますが、現実のプロジェクトで発生する例外ケースをどこまで網羅できるかは、まだ検証が必要です。
仮想案件の基本設計フェーズで、ベクトルDBの選定や認証方式の選定が出てきました。AIは各案のメリット・デメリットを丁寧に列挙します。ですが、最終的に1つを選ぶことはしません。
これは欠陥ではなく、むしろ正しい振る舞いだと思います。技術選定の最終判断は、コスト感覚、チームのスキルセット、運用体制など、ドキュメントに書かれていない文脈に依存します。AIにその文脈はありません。
対策として「複数の有力候補がある場合は人間に確認する。迷ったら止まる。」というルールを設定しました。AIが止まるべき状況（顧客の意図が不明、インプットに矛盾、スコープ変更の発生など）を明文化したことで、「自律的に進む範囲」と「人間に判断を仰ぐ範囲」の境界が明確になりました。
3つの問題はいずれも対策によって改善しました。スコープを絞り、手順書を整備し、安全弁ルールを組み込んだ結果、AI PMは手順通りに動き、適切なタイミングで人間に判断を仰ぐようになりました。
しかし「AI PMが全て主導し、人間はその指示に従う」という当初の構想は成立しませんでした。AIが自律的に動ける範囲は、人間が設計したガードレールの内側に限られます。ガードレールなしに判断の主導権まで渡すと、プロジェクトは制御不能になります。
「PMがAIを使う」こと自体は2025年から普通にやっていました。ChatGPTで壁打ちし、Geminiで議事録を取り、Claude Codeでモックを作る。ただしそれらは毎回、人間が手動で文脈を渡す必要がありました。
今回の検証で見えた現在地は、その先にあります。AIにプロジェクト全体の文脈とガードレール（手順書・安全弁ルール・ブロッキングポイント）を与えれば、定型的な工程の実行とトラッキングを自律的にやってくれる。ただし、ガードレールの設計自体は人間がやる必要がある。「AIをPMにする」はまだ早いが、「PMの実行エンジンとしてプロジェクト全体を見渡させる」は、ガードレールの設計次第で実用段階に入りつつある——というのが現時点での結論です。
ここまで「うまくいったこと」と「うまくいかなかったこと」の両方を書きました。その上で感じているのは、AIコーディングツールの恩恵を最も取りこぼしているのはマネジメント層ではないかということです。少なくとも自分の周囲では、エンジニアの間でこれらのツールの活用が進んでいますが、マネジメント層の活用はまだこれからという状況です。
先ほどのハードタスク/ソフトタスクの分類を、マネージャーの日常に当てはめてみます。
マネージャーの仕事はソフトタスクの比率が高いです。にもかかわらず、AIコーディングツールは「エンジニアのもの」として認識されがちで、マネジメント層の活用にはまだ伸びしろがあると感じています。
AIに仕事を任せるために必要なことは、実はマネジメントの基本と同じです。何をゴールにするか明確にし、必要な情報を整理して渡し、成果物を検証する。部下に仕事を任せるときにやっていることと変わりません。
逆に言えば、AIへの指示の質を決めるのは「何が課題なのか」を的確に言語化する力です。プログラミングスキルではありません。どの施策を優先すべきか、研修で何を身につけさせたいか、制度設計の落とし所はどこか——こうした問いを立てられる人間が、AIをうまく使える場面は多いです。これはマネジメント層が日常的にやっていることです。
新しいスキルを身につける必要があるというより、既に持っているスキルの適用先が広がった、という感覚に近いです。
「エンジニアにAIツールを配って、あとは各自で」というアプローチでは効果がばらつきます。どう使うか、どこまで任せるか、品質をどう担保するか。
私の場合、復帰後にまずClaude Codeを自分のPM業務に使い、並行してチュートリアルやスキルの標準化を設計し、AI PMの全任せを試して失敗しました。ヘルプで入った案件ではAIコードレビューサービスのGreptileを導入しましたが、品質は高い一方で全社展開にはコストの壁があります。そこで既存のAIツールのカスタムコマンドでレビュースキル（/code-review）を自作して比較してみましたが、正直なところGreptileほどの精度は出ませんでした。「どの案件にどのレベルのツールを入れるか」を判断できるのは、両方を自分で試したからです。
一方、本記事で紹介したCLI（ターミナル）ベースのツールは非エンジニアには敷居が高いです。ターミナルを日常的に使わない非エンジニアにとって、環境構築だけでもハードルがあります。
ただ、この壁は急速に低くなっています。Anthropicは2026年1月にClaude Coworkを発表しました。一言で言えば「Claude CodeのGUI版」で、Claude Desktopアプリ内で動作します。ターミナルを開く必要はありません。フォルダを指定し、自然言語で指示を出すだけで、Claude Codeと同じエージェント機能——ファイルの探索、情報の集約、ドキュメント作成——が使えます。Google DriveやGmailとの連携プラグインも出始めています。
本記事で書いた「設定ファイルにプロジェクトの文脈を与え、AIをアシスタントとして使う」というアプローチは、CLIでもGUIでも同じです。ターミナルに抵抗があるなら、まずClaude CoworkのようなGUIベースのエージェントツールから始めるのも現実的な選択肢です。重要なのはCLIかGUIかではなく、「プロジェクト全体の文脈をAIに渡す」という使い方に踏み出すことです。
育休前もAIは使っていました。ただ、当時のAIは「優秀な相談相手」であり、助言はくれるが実行は人間がやるものでした。各ツールがタスク単位で閉じていて、プロジェクト全体をつなぐのは自分の頭の中でした。
復帰してみると、AIが「相談相手」から「実行するアシスタント」に変わっていました。プロジェクト全体の文脈を与えれば、情報の探索と接続を自律的にやってくれます。この変化が、「コーディングツール」を「マネジメントツール」に変えています。
一方で、その先——AIにPMの座を渡す試みは失敗しました。今の実用的な境界線は「プロジェクト全体を見渡すアシスタント」であって、「判断する主体」ではありません。
日常的に情報整理と判断を仕事としている方へ。CLIに慣れているならCLAUDE.md（あるいはAGENTS.md、GEMINI.md）に「PMとして振る舞え」と書くところから。ターミナルに抵抗があるならClaude CoworkのようなGUIツールから。入口はどちらでも構いません。試してみると、返ってくるものの質が「仕事に関わる情報がどれだけファイルに書かれているか」で決まることに気づくはずです。そこから先は、言語化と指示出しというマネジメント層が得意なことの延長です。