## はじめに

先日公開された「[AIエージェントを中心に据えた開発環境への移行](https://sterfield.co.jp/blog/ide-to-ai-agent/)」は、エンジニアがIDEからAIエージェントへ作業の中心を移した話でした。同じ構造の転換を、自分はエンジニアではない立場で進めてきました。

**時代が大きく変わるという危機感と、この技術が業務のかたちをどこまで変えるのか、自分の手で確かめたいという衝動から、自分で業務環境の中心にAIエージェントを据え直してきました**。Claudeを中心に据えた直近1ヶ月で、景色は大きく変わっています。誰かに導入されたのではなく、自ら設計し、試し、組み替えてきたプロセスです。

**AIエージェント活用はもう、エンジニアの世界だけの話ではなくなっている**——と、自分の手を動かしながら感じています。

本記事は、この1ヶ月で何を考え、何を組んだかの共有です。

## 以前の業務環境

半年ほど前の業務環境は、おおむね以下のようなものでした。

- コミュニケーション:Gmail、Google Chat、Chatwork、Teams、Slack
- 案件管理:Backlog(4スペース)、GitHub
- スケジュール:Googleカレンダー
- AI:ChatGPTやGeminiをブラウザから日常的に活用(メール下書き、議事録要約、モックアップHTML、提案書の構成まで)

毎朝、ブラウザを開けばGmail、Google Chat、Chatwork、Teams、Slack、Backlog、GitHub、カレンダーのタブが20も30も並んでいました。そこからChatworkの100を超えるルームのうち動いているものを流し見て、Backlogの4スペースを横断して新着コメントを拾い、カレンダーで当日の予定を確認する。

情報を**集める作業**と、集めた情報をもとに**判断する作業**が、完全に同じ人間(=自分)に重なっていました。AIの出番は多かったのですが、業務の外側にいて、用事があるときに呼び出す外注のような位置づけでした。

## 今の業務環境

現在は、以下のような構成になっています。

- 作業の中心:ターミナル上のClaude Code、Claudeデスクトップアプリ、Cowork、Claude in Chrome
- CLAUDE.mdに会社文脈・担当案件・業務プロトコルを事前に添えている
- 役割別エージェントを3体制で運用(.claude/agents/ 配下に定義)
- 業務アプリはブラウザで開くだけでなく、ターミナルから取れるものは取る(GitHubはgh CLI経由など)

朝、PCを立ち上げて「おはよう」と打つと、昨日以降に動いたメール、Chatworkの動き、BacklogとGitHubの新着、カレンダーの予定、判断が必要な論点が、ひとつのブリーフィングとして返ってきます。

情報を**集める作業**そのものが、業務から消えました。

![スクリーンショット-2026-04-23-12-25-22-png-1542×1662--04-23-2026_01_52_PM.png](https://cont.sterfield.co.jp/uploads/2026_04_23_12_25_22_png_1542_1662_04_23_2026_01_52_PM_1038e4decf.png)

同じ構造は、朝のブリーフィング以外の領域にも広がっています。

たとえば提案書づくり。業界リサーチや先方の公開情報の読み込み、競合との差別化の整理、構成のたたき台、スライドのドラフトまで、AIが先回りで組み立てます。自分は要件や論点の解像度を上げる壁打ち相手として回り、何度も応酬を重ねて提案の輪郭を整える、という進め方になりました。最終成果物に至るまでの試行回数は、以前とは比較にならないくらい増えています。

かかる時間そのものは、意外にも劇的には減っていません。ただし、**使っている脳がまったく違う**というのが一番の実感です。手でゼロから資料を作っていた時代は、構成を考える脳・文字を打つ脳・体裁を整える脳が一度に動いていました。今は、方針を示す脳・論点を足す脳・最後に判断する脳だけが残っています。**作業の実行者から、判断と編集の責任者へ**と、自分の役割が移ったような感覚です。時間ではなく、疲れ方と発想の出方が変わりました。

社内の案件引き継ぎ書も同じです。関連するBacklog、Chatwork、Gmail、GitHub上のやりとりや関連ドキュメントをAIに読み込ませたうえで、事実ベースのドラフトを組み立てさせています。人間の記憶や印象で書いた引き継ぎ書より、データから再構築されたほうが明らかに精度が高く、抜け漏れも減りました。

## AIにはまだできないこと

人間の残された仕事のうち、大きなもののひとつが、**ドキュメントに残らない暗黙知を最後に添えて仕上げる**作業です。案件ごとの特殊事情、現場の温度感、その場でしか判断できない機微——こうした情報はどんなドキュメントにも書ききれません。事前に添えた文脈と、その場で添える暗黙知。両方あって初めて、AIが自分の代わりに考えてくれる状態に近づきます。

この延長で、情報の残し方そのものも意識するようになりました。たとえばオンライン会議では、アクションアイテムが決まった瞬間にあえて大きめの声で復唱しています。参加者への明確な共有でもありますが、AIが文字起こしから議事録を組み立てる際に、重要ポイントが確実に拾われるようにするための工夫です。日常の所作のなかに、**AIが後から読み取れる形で情報を残す**という意識が混ざるようになりました。

## 何が変わったのか

半年前の時点でも、ChatGPTやGeminiは一日に何度も呼び出して使っていました。下書きや要約はもちろん、モックアップHTMLの生成や提案書の構成まで任せていて、それで一通りの業務は回せていたのです。

そこから変わったのは、業務のなかでAIを**呼ぶ**立ち位置から、業務のなかにAIが**組み込まれている**立ち位置への移行でした。

### AI活用の4つの階層

この変化は、AI活用の階層として整理するとわかりやすくなります。自分の実感では、AI活用にはおおむね以下の4段階があります。

- **レベル1:代替** — 人の作業を置き換える(要約、翻訳、下書き)
- **レベル2:比較検討** — 複数案を出させて選ぶ、壁打ち相手として使う
- **レベル3:思考の外部化** — 自社の文脈や判断基準を事前に渡した上で、AIとの応酬を重ねながら使う
- **レベル4:業務の再設計** — レベル3のAIを特定業務の専任としてフローに組み込む

半年前の自分はレベル1〜2を行き来していました。今はレベル3〜4にいる、という整理になります。

レベル2から上に進むために必要だったのは、技術や知識ではなく、2つのことでした。

ひとつは、**AIに渡す文脈を整えること**。「どのツールが一番いいか」「どのプロンプトが効くか」といった議論は、それ自体は自然で、自分も通ってきた道です。ただ、そこだけで時間を使っていると、レベル2の内側で留まりやすい。自分の業務・判断軸・自社の事情をAIに渡す準備を始めた瞬間から、景色が変わります。

もうひとつが、**圧倒的な試行回数**です。ひとつのアウトプットに対して、20回、30回と応酬を重ねる。「一度で正解が出る」ことをAIに期待している間は、どれだけ高性能なモデルを使ってもレベル2の内側から出られません。試行回数を前提にした瞬間に、AIとのやりとりは「正解を引く」作業ではなく「正解をつくる」作業に変わります。この切り替えが、階層をひとつ上げます。

ただし、レベル3からレベル4に進む段階では、**最低限のIT的な感覚**がまったく不要かといえば、それは嘘になります。たとえば、使っている業務ツールにAPIがあるかどうかを調べ、「APIがあるならAIに情報を取って来てもらえそう」「ないなら別の手を考える必要がある」と判断できる感覚です。高度な技術知識は要りませんが、こうした**ツールとツールが繋がる仕組みの見当**がつくと、設計の幅が明らかに広がります。

むしろエンジニアでない立場からだと、最初にぶつかるのはこの**接続点**ではないかと感じています。文脈を整えるところまでは自力でできても、AIをどの業務ツールに、どう繋ぐかの絵が描けない。ここは独学でもある程度は進めますが、身近にいるエンジニアと組んで小さな仕組みを一つ作ってみるのが、一番早い抜け方だと思います。大がかりなことを学ぶ必要はなく、「Claude CodeがGmailを読める状態を一度作る」くらいから十分です。

ここから先は、自分がレベル3〜4にどう登ったかを順に書きます。

### 1. CLAUDE.mdによる文脈の事前装填(レベル3への移行)

1つめは、CLAUDE.mdに自分と会社の文脈を添えるようにしたことです。

役職、事業、担当案件、パートナー企業、定例会議、ツール構成、Gmailのラベル体系、勤務パターン——これらの前提を、Claude Codeが毎回参照できる状態にしました。

この作業は、技術の話というより、**自分の業務を客観視して、AIに渡す文脈を整える作業**でした。普段は無意識にやっていることを、AIが使える形で整理する必要があります。

やってみてわかったのは、これをやる前と後では、同じ質問に対するAIの返答がまるで別物になるということでした。「この案件、どう進めますか」という一言で、クライアントの背景・過去の経緯・社内の担当者・判断基準まで踏まえた回答が返ってくる。文脈を毎回ゼロから伝える必要がなくなる。

出力の精度は、**AIの性能ではなく、どれだけの文脈を渡せているかで決まる**。これが一番大きな発見でした。

文脈は、業務情報だけではありません。Claudeには個人設定という、すべての会話に共通で適用される設定欄があります。自分はここに、たった一文だけ書いています——**「嘘はつくな。出来なかったら出来ないといえ」**。

![スクリーンショット 2026-04-24 15.22.41.png](https://cont.sterfield.co.jp/uploads/2026_04_24_15_22_41_87061cffef.png)

たった一文ですが、これがよく効きます。知らないことを知ったかぶりで埋めてこない。推測で架空の情報を生成しない。「その情報は持っていません、確認させてください」と正直に返してくる。業務パートナーとして一緒に仕事をするうえで、この一文があるかないかで信頼の置き方がまったく変わります。この記事も、事実と推測が混ざらないまま書き上がったのは、この設定のおかげが大きいと感じています。

### 2. 役割別エージェントによる業務分業(レベル4への移行)

2つめは、ひとつのAIに全部を頼むのではなく、役割ごとにエージェントを分けたことです。

現在は3体制で運用しています。情報を**集める方角**を担うCompass(羅針盤)、課題の**解に向かう方角**を担うSolver(解決者)、判断の**拠り所**を担うAnchor(錨)。それぞれ起動ワードで呼び分けます。

この3体制に至るまでに、何度か編成を組み替えました。最初は「資料作成担当」「レポート担当」「コーチ担当」のように**機能名**で分けていましたが、しばらく回すうちに、機能名だと依頼する側が「今どれを呼ぶべきか」を毎回考える必要が出てきて、かえって思考のリズムを止めることに気づきました。

Compass / Solver / Anchor という抽象語に切り替えたのは、「どこに向かわせるか」という**方角**で分けたほうが、依頼する自分の思考が先に整理されるからです。「今から自分はCompassで情報を集めに行く」「今はAnchorで判断の拠り所がほしい」——どのエージェントを呼ぶかを選ぶ瞬間が、そのまま**今から自分は何をしようとしているのか**の宣言になります。

エージェントの命名は、AIに仕事を振るためのラベルではなく、**自分の業務モードを切り替えるスイッチだった**、というのが今の実感です。

### 3. 業務アプリの立ち位置の変化

この2つが組み合わさった結果、業務アプリ(Gmail、Chatwork、Backlog、GitHub、カレンダー)を**自分から巡回する時間**が大きく減りました。業務アプリ自体は今でも日中ずっと開いていて、個別のやりとりやリアルタイムの反応は直接見ています。変わったのは、「まず自分が巡回して情報を集める」という**入口の役割**がAI側に移ったこと。業務アプリは、情報を能動的に取りに行く場所から、必要に応じて直接触れる場所へと、位置づけが変わりました。

範囲は業務アプリだけにとどまりません。Web、社内ドキュメント、過去のやりとり——**AIはすでに外部脳と接続された状態**で待っています。自分でブラウザを開いて検索して、タブを行き来して、コピペで集めて、という手作業を踏まなくても、「この件について必要な情報を集めて」と一言渡せば、ガッと集まってくる。調べる時間と、集めたものを使って考える時間の境目がなくなりました。

判断する人間は自分ひとりですし、最終承認も自分のところで止まります。それでも「情報を集めるのに午前中を使う」が消え、「集めた情報を判断する」と「判断したものを実行する」に時間を寄せられるようになったのは、大きな変化でした。

ここまでClaude系のツールを中心に書いていますが、使っているAIはClaudeだけではありません。用途に応じてGemini(とくにGems)もGensparkも使っています。レベル3の「文脈を事前に渡す」という工夫は、ClaudeのCLAUDE.mdでもGeminiのGemsでも、本質的に同じことが実現できます。自分にとって本質は、どのAIを使うかではなく、**業務の前にAIを先回りさせる構造**が作れているかどうかです。ツールは数ヶ月単位で入れ替わりますが、**この構造はツールを超えて残ります**。

## まとめ

**「AIを業務アプリのなかで使う」から「AIを中心に置いて業務アプリを脇に置く」へ**。開発環境で起きた構造の逆転は、業務環境でも同じ形で起きるというのが、この1ヶ月の一番の実感でした。

特別な技術は必要ありませんでした。必要だったのは、自分の業務と判断軸を整理してAIに渡すこと、書ききれない暗黙知を都度添えること、そして**「正解をつくる」ための圧倒的な試行回数を惜しまないこと**——エンジニアでない立場でも、十分に踏める道です。ツールもClaudeに限った話ではなく、GeminiのGemsで同じ階層までは行けます。

そして何より、**自分がこの時代の仕事の仕方を、心から楽しんでいます**。朝、ターミナルに「おはよう」と打つところから始まる一日。自分の手が届く範囲がどんどん広がっていく感覚。業務の中心を動かしにいく過程そのものが、面白くて仕方ありません。この面白さが伝われば、この記事は十分に役目を果たしたと思っています。

large_eyecatch-03-terminal.png

medium_eyecatch-03-terminal.png

small_eyecatch-03-terminal.png

thumbnail_eyecatch-03-terminal.png

eyecatch-03-terminal.png

AIエージェントを中心に据えた業務環境への移行

## はじめに

前回の記事「[Claude Codeで始めるISSUE駆動開発](https://sterfield.co.jp/blog/claude-code-issue/)」を公開したのが2025年12月でした。それから約4ヶ月、自分の開発環境は当時とはかなり違うものになっています。特にIDEをほぼ開かなくなったのが、一番の変化でした。

本記事では、12月時点の環境からどのように変わったのか、そのきっかけとなったツール導入や運用の変化を振り返ります。

## 12月時点の環境

前回記事を書いた頃の開発環境は、以下のようなものでした。

- エディタ：Visual Studio Code（以下、VSCode）
- AI：Claude Code（VSCode拡張機能）

VSCodeの中ですべてが完結していました。Claude Codeは拡張機能としてサイドパネルに常駐し、指示はそこで出す。コードはエディタで読み書きする。GitHub ISSUEの読み書きやgit操作も含めて、日々の開発はほぼこの一画面で回せていました。IDEが作業の中心だった、という言い方がしっくりきます。

## 今の環境

現在の環境は、以下のようになっています。

- エディタ：[Zed](https://zed.dev/)（たまに開く程度）
- AI：Claude Code CLI、[cmux](https://cmux.com/ja)で複数セッションを同時起動
- Markdownプレビュー：[mo](https://github.com/k1LoW/mo)、もしくはPRを作ってGitHub上で確認

作業の中心はターミナルに移りました。

Claude Codeにタスクを渡したら、あとはエージェントが動きます。コードを確認したくなったときだけZedを開いて眺める程度で、編集することはほぼありません。このブログ記事の執筆も同じ流れで、プレビューはターミナルからmoを叩くか、PRを作ってGitHub上で確認するのが基本です。

## 何が変わったのか

12月時点でも、Claude Codeを使って一通りの開発は回せていました。VSCodeを開き、拡張機能を通じてClaude Codeに指示し、一つの作業を一つずつ進める。それで十分機能していたのです。

そこから変わったのは、複数の作業を同時に走らせられるようになったことです。きっかけは主に2つありました。

### 1. cmuxによる複数セッションの並走

1つめは、[cmux](https://cmux.com/ja)の導入です。

cmuxは、Claude Codeをはじめとするコーディングエージェントを複数同時に実行・管理するためのデスクトップアプリケーションです。各セッションを独立したタブとして扱い、それぞれのエージェントの状態を一目で把握できます。現時点ではmacOSのみの対応です。

画面には常に4〜5個のClaude Codeが並んでおり、それぞれ別のリポジトリ、別の機能、別のバグを担当しています。一つにバグ修正を頼み、別のセッションにリファクタを投げ、さらに別のセッションでドキュメントを書かせる。どれかが考えている間に、どれかが実装を終えている。以前なら順番にこなしていた作業が、いくつもの並列レーンで同時に進んでいく感覚は、これまでの開発体験にはなかったものです。

![cmuxで複数のClaude Codeセッションを並走させている様子](https://cont.sterfield.co.jp/uploads/cmux_parallel_sessions_83c193db65.png)

### 2. git worktreeを使ったPRレビュースキルの整備

2つめは、git worktreeを活用してPRをレビューするためのClaude Codeのスキルを整備したことです。

worktreeで別ディレクトリにPRブランチをチェックアウトし、そのディレクトリ上でClaude Codeを立ち上げてレビューを進める、という仕組みです。これを整えたことで、メインの作業ツリーで別ISSUEの開発を進めながら、同じリポジトリのPRレビューも並行して走らせることができるようになりました。

worktreeを使わずにブランチを切り替えてしまうと、進行中の作業が一時的に止まってしまいます。worktreeを前提にすることで、作業の文脈を切らずにレビューだけを別トラックで走らせられるようになりました。

### IDEの立ち位置の変化

この2つが組み合わさったことで、同一リポジトリ内の複数作業はもちろん、別リポジトリの作業までも並行できるようになりました。そうなると、作業の中心は自然とターミナルに寄っていきます。

VSCodeはもともと「書く・読む・実行する」のすべてをこなす場所でしたが、今はZedに乗り換えた上で「読む」しかしていません。しかも常時開いているわけでもなく、必要なときだけ立ち上げるスタイルです。

もちろん人間側のボトルネックはあります。5つのPRが同時に上がってくれば、レビューするのは自分ひとりです。それでも「手が足りないから諦める」が減り、「やりたいことを同時に走らせてみる」が選択肢に入ってきたのは大きな変化でした。一人で開発しているのに、まるで小さなチームを抱えているような気分になります。

## まとめ

「AIをIDEの中で使う」から「AIを中心に置いてIDEを脇に置く」へ。構造の逆転が起きたというのが、この4ヶ月の一番の実感です。ツール選びの軸も「書きやすさ」から「エージェントとの並走のしやすさ」に変わりました。

cmuxによる複数セッションの並走、git worktreeを活用したレビュースキルの整備。どちらも派手な話ではありませんが、組み合わせることで「一人で複数のエージェントを指揮する」開発スタイルが現実のものになりました。

Claude Codeを日常的に使っている方は、ぜひcmuxやworktreeとの組み合わせも試してみてください。開発の体験が一段変わると思います。

large_eyecatch.jpg

medium_eyecatch.jpg

small_eyecatch.jpg

thumbnail_eyecatch.jpg

eyecatch.jpg

AIエージェントを中心に据えた開発環境への移行

## はじめに

Anthropicが提供するCLIベースのAIコーディングエージェント「Claude Code」を使った開発ワークフローをご紹介します。

Claude Codeの特徴は、ターミナル上で動作し、GitHubのISSUEやPRと直接連携できる点です。これにより、ISSUEを起点とした開発フローを非常にスムーズに進めることができます。

## Claude Codeとは

[Claude Code](https://docs.anthropic.com/ja/docs/claude-code/overview)は、Anthropicが提供するCLIベースのAIコーディングエージェントです。ターミナルから自然言語で指示を出すだけで、コードの生成・修正からGit操作まで一連の開発作業を自律的に進めてくれます。

Claude Codeの基本的な使い方やインストール方法については、[前回の記事「Claude有料版を初めて使う開発者向けガイド」](/blog/blog-32/)で詳しく解説していますので、そちらをご覧ください。

本記事では、Claude Codeの中でも特に強力なGitHub連携機能を活用した「ISSUE駆動開発」のワークフローに焦点を当てて紹介します。

## ISSUE駆動開発とは

ISSUE駆動開発は、ISSUEを起点として開発を進める手法です。GitHubやGitLabなど、ISSUEトラッカーを持つサービスで実践できます。すべての作業がISSUEに紐づくため、以下のようなメリットがあります。

- トレーサビリティ: なぜその変更が行われたかが明確
- チーム連携: 作業状況の可視化と共有が容易
- 品質管理: レビューとテストのプロセスが明確

## Claude CodeによるISSUE駆動開発ワークフロー

Claude Codeを使うと、ISSUE駆動開発が驚くほどスムーズになります。以下に実際のワークフローを紹介します。

Claude CodeはCLAUDE.mdという設定ファイルでカスタマイズできます。今回のワークフローでは、CLAUDE.mdという設定ファイルに「ISSUEのURLが提供された場合はghコマンドで内容を確認する」といった指示を記述しておく必要があります。

### 1. ISSUEの確認と計画立案

```
> #123のISSUEに対応してください
```

このように指示すると、Claude Codeは以下を自動で行います。

1. `gh issue view 123` でISSUEの内容を取得
2. 要件を分析し、TODOリストを作成
3. 仕様や設計に不足があれば指摘し、見直しを促す
4. 作業計画を提示して確認を求める

ここで重要なのは、AIとの議論を通じて明確になった仕様や設計をISSUE側に反映させることです。これにより、ISSUEが単なるタスク管理ではなく、ISSUEが開発の意図や設計の背景を記録した、生きた仕様書として機能するようになります。

### 2. ブランチ作成と実装

計画が承認されると、Claude Codeは以下のワークフローを実行します。

1. フィーチャーブランチを作成（例: dev/123_add-user-validation）
2. 必要なファイルを特定し、コードを実装
3. 動作確認やテストを実行
4. 問題があれば修正を繰り返す

### 3. PRの作成とレビュー依頼

実装が完了すると、Claude Codeは変更内容をまとめたPRを自動作成します。

```
> PRを作成してください
```

PRには以下が自動で含まれます。

- 変更内容のサマリー
- テスト計画
- 関連するISSUEへのリンク

## やってみた所感

実際に3ヶ月間、このワークフローで開発を続けてきました。その中で得られた気づきを共有します。

### 既存プロジェクトへの導入のしやすさ

最も大きなメリットは、今まで使っていたGitHub ISSUEをそのまま活用できる点です。新しいツールやフローを導入する際、既存の運用を変える必要があると導入コストが跳ね上がりますが、Claude CodeはGitHubのISSUEを直接読み込んで内容を理解するため、既存のプロジェクト管理をそのまま維持できます。

この3ヶ月間、ほぼ全ての実装作業をClaude Codeに任せることができています。ISSUEを起点にした開発フローが確立されていれば、導入は驚くほどスムーズです。

### AIを信じて任せることの重要性

運用を続ける中で気づいたのは、細かくやり方を指示しすぎない方がAIの能力を発揮してくれるということです。

最初は「このファイルを開いて」「この関数を修正して」と細かく指示を出していましたが、それではAIの自律性を活かせません。「#123のISSUEに対応して」とだけ伝え、計画立案から任せる方が、結果的に質の高いアウトプットが得られます。人間が想定していなかったより良いアプローチを提案してくれることも少なくありません。

### 伴走スタイルがベストプラクティス

一方で完全に自律させるのではなく、あくまでも「伴走」というスタンスを維持することをおすすめします。

AIに複数のタスクを並列で任せたり、完全に放置して自律的に進めさせることも技術的には可能です。しかし、そうすると人間側のレビュー工数が一気に増え、かえって非効率になります。1つのタスクをAIと一緒に進め、要所要所で確認しながら進める「伴走スタイル」が、現時点ではベストプラクティスだと感じています。

「人間がISSUEを作成し、AIが実装する」という一方通行の役割分担ではなく、ISSUEを軸に人間とAIが協働しながら開発を進める。これがClaude Codeを活用したISSUE駆動開発の醍醐味だと感じています。

## まとめ

Claude Codeを使ったISSUE駆動開発は、開発ワークフローを大きく効率化する可能性を秘めています。特に、ISSUEの確認からPR作成までの一連の流れをAIがサポートしてくれることで、開発者はより本質的な設計や問題解決に集中できます。

設定ファイルを活用すれば、チームのコーディング規約やワークフローをClaude Codeに教え込むことも可能です。これにより、チーム全体で一貫した開発スタイルを維持しながら、AIの力を借りることができます。

AIコーディングエージェントはまだ発展途上ですが、開発者の強力なパートナーとなる未来は確実に近づいています。皆さんもぜひ、Claude Codeを使ったISSUE駆動開発を体験してみてください。

Company

Our Solutions

Support

News

Blog

Blogブログ

カテゴリーから探す

年別から見る

記事一覧 - タグ: #ClaudeCode

2026/04/24

2026/04/17

2025/12/26