実際のプロジェクトでAIエージェントと働いた3時間：記録と数字

この現場ノートは、確かめられる2つの情報源から測っています。このブログのプロジェクトのgit履歴と、筆者とAIエージェント（Claude Code）とのチャット履歴です。組み立てた数字はありません。

先に限界を述べます。これは1回の作業、1つのプロジェクト、人とエージェントの1組で、対照群はありません。ある具体的な姿を示すものであり、すべてのプロジェクトについて何かを証明するものではありません。

---

要点#

• 最初のコミットから最後のコミットまで3時間18分で、エージェントと人は合計6,922行の追加または削除を伴う12コミットを作りました。
• 人は33通のメッセージを送りました。コミットの指示が11、新しい作業の依頼が7、不具合の報告ややり直しの依頼が15（約45%）です。
• 12コミットのうち7つはフィードバックを受けた修正でしたが、合計で323行、変更行数の約**4.7%**にすぎません。小さな不具合が、何回転もかかります。
• 人が見つけた不具合の大半は目に見えるものでした。箱の中の箱、欠けた丸、違う言語の文字、かたい言い回し。少なくとも4つは、当時その種類のチェックがなかったために自動チェックをすり抜けました。
• あるとき、エージェントは場所を間違えて直しました。ラベルを動かしましたが、本当の原因は画像の枠でした。直す前に測ることで原因が分かりました。
• 実践的な学び：不具合のたびに、新しいチェック1つと、プロジェクトの手引きに1行を残すこと。

---

1. 背景#

プロジェクトは、この個人の静的ブログです。Markdownの内容、手書きのページ生成器、3言語（ベトナム語、英語、日本語）、そしてスライドです。作業中、筆者はメッセージでエージェントに仕事を渡し、エージェントはファイルを読んで直し、ビルドとチェックのスクリプトを走らせ、人がブラウザで結果を見て返信しました。コミットは人が指示したときだけ作られました。

これは「エージェントが一晩ひとりで走る」やり方とは違い、人がそばに座って絶えずフィードバックする形です。数字を読むときはこの点に留意してください。

---

2. コミットの記録#

時刻はgitの履歴によるものです（現地時間、同じ日）。「種類」はコミットの接頭辞です。

大きな納品のたびに、その後に修正が続きました。チームワークのスライドの後、最初の修正は6分後。SEOの一式の後、最初の修正は7分後、本当の原因の修正は11分後でした。

---

3. 数字#

メッセージの分類の方法：「不具合報告ややり直し」は、納品した結果に誤りがある、分かりにくい、意図と違う、と伝えるメッセージです。「新しい作業」は、内容や機能の追加の依頼です。分類は手作業で、いくつかのメッセージは議論の余地があります。

最も印象的なのは、**12コミット中7つ対、行数の4.7%**です。労力の大半は、文章の量ではなく戻る回数にあります。

---

4. 人が見つけた11の不具合#

エージェントより先に人が見つけた代表的な不具合です。最後の列は根本原因を示します。

分類：言葉が4、言語が2、見た目が2、体験が1、美的感覚が1、診断の誤りが1。

注目すべき点： これらはどれもプログラムの論理の誤りではありません。結果が目にどう見えるかにあり、人が画像を渡さないかぎりエージェントには目がなく、自動チェックにも見るよう教えていませんでした。

---

5. 自動チェックは捉えたか#

エージェントはチェックのスクリプトを書きました。スライドの配置（はみ出し、重なり、タイトルの折り返し）と、その後は言語が漏れた文字の検査です。これらは人が見る前に多くの不具合を捉えました。しかし上の表のうち少なくとも4つは、当時その種類のチェックがなかったためにすり抜けました。

• 不具合7、8、10、11：配置のチェックは「問題なし」と言うか、存在しなかったのに、人は間違いを見つけました。配置のチェックは「違う言語に文字が漏れていないか」「ページが正しいテーマを示しているか」「動くあいだに丸が欠けないか」を問いません。

そのたびの正しい対応は、新しいチェックを足すことでした。言語漏れの検査、4つの幅での丸とラベルの間隔の測定、「タイトルはテーマを示すこと」という規則です。自動チェックは、人が出会う不具合とともに育ちます。

不具合11はよく読む価値があります。間隔の測定は重なりなしと示しましたが、犯人は丸が跳ね上がるときに形を切るSVGの枠でした。動きの頂点で不具合を再現し、形と枠を比べて初めて原因が分かりました。教訓：直す前に測り、まさにその状況を再現する。

これはAIを鵜呑みにしてはいけない理由と同じ型です。結果は完成して見え、内部のチェックは問題なしと言い、見た人が間違いを見つけます。

---

6. 6つの学び#

1. 人のフィードバックは、おもに見ること、感じることについて。 絵、言葉、名前、配置。人が指摘するのを待つのではなく、エージェントが自分の結果を見られる手段（スクリーンショット、スクリプトでの測定）を用意します。
2. 費用は行数ではなく回転数にある。 7つの修正コミットは323行だけ。費用を下げるには、最初から「完成とは何か」を示して戻る回数を減らします。
3. 自動チェックは教えられたことしか捉えない。 不具合のたびにチェックを足します。さもないと同じ種類が戻ってきます。
4. 直す前に測る。 最初の丸の修正は、最初にもっともらしい推測に従ったため外れました。不具合を最悪の状態で再現します。
5. エージェントは言葉に従う。 人が「AではなくBへ向かう」と言うと、エージェントはそのままタイトルに写しました。依頼文を写さず、言い換えるよう求めます。
6. 学びをプロジェクトの手引きに書く。 繰り返す不具合は、案内ファイルの1行になります（AI向けの手引きを参照）。このプロジェクトには現在、4つの専用の手引きと1つの共通の注意書きがあり、項目のほとんどが上の不具合から生まれています。

---

7. このノートの限界#

• 1回の作業、1つのプロジェクト、1組。 一般的な水準は推測できません。これは内容と見た目のプロジェクトで、目に見える不具合の比重が大きいものです。バックエンドのプロジェクトなら別の姿になります。
• 対照なし。 人が1人でやったらどれくらいかかったかは分からず、エージェントが速かったか遅かったかは言えません。以前の記事で触れたMETRの研究が警告したとおり、速く感じることは速いことではありません。
• 手作業の分類。 メッセージと不具合は手で分けており、別の人は数件を違うところに入れるかもしれません。
• 時間はコミットから。 コミットは人が指示したときだけ作るため、実際の作業は2つのコミットの間隔より長くなります。
• 測っていないこと： 人が見て、フィードバックを打つのにかけた時間、読者から見た品質、エージェントを使う費用。

---

8. 自分のプロジェクトで測る#

小さな記録があれば、自分の数字が得られます。エージェントに渡した作業ごとに1行です。

2つのコマンドを添えます。

git log --format='%h %ad %s' --date=format:%H:%M --shortstat
git diff --shortstat <作業前のコミット> HEAD

1週間後、3つの数字を読みます。何件の作業が2回転より多くかかったか、どの種類の不具合が最も繰り返されるか、誰が不具合の大半を見つけるか。この3つが、自動チェック、手引き、仕事の渡し方のどれに投資すべきかを教えてくれます。

---

9. 結論#

3時間で、エージェントは大量の成果を素早く作り、人は、人の目にしか見えない小さな点のために何度も戻らなければなりませんでした。どちらも本当です。エージェントのそばに座る価値は、修正のたびにチェックか手引きの1行に変えることにあり、次にその不具合を人が指摘する必要がなくなります。

このノートは1つの標本にすぎませんが、測り方は再利用できます。あなたも1週間を記録すれば、その数字は、他の誰のレポートにも代わりに言えないことを語ってくれます。

---

参考資料#

数字は、このプロジェクトのリポジトリのgit履歴（コミット 3791938 から ec1bc85）と、作業のチャット履歴によります。リポジトリ内の関連記事：

• AIを鵜呑みにしてはいけない理由（METRの研究、Stack Overflow Developer Survey 2025、AIが書いたコードの研究の出典を含む）
• AI時代のITチームの働き方（Faros AIとDORA 2025の出典を含む）
• AIが書いたコードのレビュー
• AI向けの手引き

外部の参考資料：

• git log と git diff（公式ドキュメント。「自分で測る」で使うコマンドの出典）
• Faros AI：AIの生産性、実験室と現実 と DORA 2025 は、比べるための大規模な情報源です。この記事は小さな標本にすぎず、それらの代わりにはなりません。