Ghostty作者 Mitchell Hashimoto の AIエージェント活用法【具体例つき】

Mitchell Hashimoto 氏は、ハイプに踊らされない「元・AI懐疑派」の立場から、AIエージェントとの付き合い方を語ります。鍵は「チャットボットではなくエージェント」「リサーチから始める」「ハーネスエンジニアリング」、そして人間が専門家・レビュアーであり続けること。本記事では具体例とともに紹介します。

本記事は、Mitchell Hashimoto 氏のブログ（mitchellh.com、一次情報）と、それを報じた The Pragmatic Engineer（二次情報）を当社が調査したものです。X（旧Twitter）からの引用は文言の最終確認を推奨します。出典は記事末尾に記載しています。

1. 「チャットボット」ではなく「エージェント」を使う

氏がまず強調するのは、価値が出るのはエージェントであってチャットボットではない、という点です。エージェントとは「チャットでき、ループの中で外部の振る舞いを起動できる LLM」で、最低限ファイルを読み、プログラムを実行し、HTTP リクエストを送れるものを指します。氏自身、当初は Claude Code に「あまり感心しなかった」と正直に書きつつ、ツール採用には必ず3つの段階があるとします。

(1) a period of inefficiency (2) a period of adequacy, then finally (3) a period of workflow and life-altering discovery.

— My AI Adoption Journey (2026-02-05)

2. まず「リサーチ」を委譲する

氏が AI 懐疑派に勧める入口は、コード生成ではなくリサーチの委譲です。これが最もリスクが低く、見返りが大きいといいます。

There's a lot of people like, "I don't want it to write code for me." But just delegate some of the research part.

— The Pragmatic Engineer（二次情報・本人発言の引用）

具体的には、自身のブログで次のような使い方を挙げています。

• ディープリサーチ：「特定の言語で、特定のライセンス種別を持つライブラリをすべて洗い出す」ような調査を任せ、各候補の長所/短所/活動状況/評判を数ページにまとめさせる
• 並列エージェント：「やってみたいが手をつける時間がなかった曖昧なアイデア」を複数のエージェントに同時に試させる

3. 具体例：Ghostty での実践

抽象論ではなく、自身の大規模 OSS プロジェクト Ghostty での実例を公開している点が氏の特徴です。

The command palette that ships for macOS in Ghostty today is only very lightly modified from what Gemini produced for me in seconds.

— My AI Adoption Journey (2026-02-05)

さらに、macOS 版の「控えめな自動アップデート通知」機能を作った過程を "Vibing a Non-Trivial Ghostty Feature" として詳細に記録。具体的な数字まで開示しています。

注目すべきは、あるバグを直すのに約4回失敗して戦略を変えたと書いている点です。エージェントを放任して回したのではなく、人間が介入し、アプローチを切り替えた——ここに氏の流儀が表れています。

4. 「ハーネスエンジニアリング」

氏の中核概念がハーネスエンジニアリング（harness engineering）です。定義はこうです。

Anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.

— My AI Adoption Journey (2026-02-05)

つまり「エージェントがミスをするたび、そのミスを二度と犯さないよう解決策を作り込む」。手段は2種類あるとします。

• 暗黙のプロンプト改善（AGENTS.md） — 実際に Ghostty のリポジトリには src/inspector/AGENTS.md という実ファイルがあります
• 実際にプログラムしたツール — スクリーンショットを撮るスクリプトや、絞り込んだテストを走らせるスクリプトなど

検証についても、Boris Cherny 氏や Simon Willison 氏と響き合う言葉を残しています。

If you give an agent a way to verify its work, it more often [than] not fixes its own mistakes and prevents regressions.

— My AI Adoption Journey (2026-02-05)

5. 「エージェント精神病」という戒め

そして氏の最も鋭い警告がこれです。レンダラーを最適化させたエージェントが、フレーム時間を 88ms → 2ms、アロケーションを 約15万 → 500 に削減した、という「すごい成果」を出しました。しかし——

Sounds good, right? Wrong. This is exactly why agent psychosis is a big fucking problem.

— Mitchell Hashimoto 氏の X 投稿（一次情報・文言は要確認）

実は氏が手で書き直した版は約 0.02ms（エージェント版の約75倍速）、アロケーションはゼロでした。「もっともらしく見える結果」を鵜呑みにする危うさ——氏はこれを「エージェント精神病（agent psychosis）」と呼び、最大の戒めとしています。

実際の設定・使い方の例

Hashimoto 氏の「まずリサーチを委譲する」「ハーネスエンジニアリング」「費用と稼働の目安を持つ」という実践は、Claude Code の具体的な使い方として次のように再現できます。

1. リサーチを委譲する（claude -p）

氏が AI 懐疑派に最初に勧めるのがリサーチの委譲です。非対話の -p で、調査タスクをそのまま任せられます。

# 特定言語・特定ライセンスのライブラリを洗い出し、比較表にまとめさせる
claude -p "調査: Rust で MIT/Apache-2.0 ライセンスの HTTP クライアントを列挙し、各候補の長所・短所・活動状況・評判を表にまとめて"

2. ハーネスとしての CLAUDE.md / AGENTS.md

「エージェントがミスをするたび、二度と繰り返さないよう作り込む」——その暗黙のプロンプト改善が、リポジトリに置く CLAUDE.md（または氏の使う AGENTS.md）です。ミスを見つけたら、そのつどここに追記していきます。

# AGENTS.md（ハーネスの例：ミスを見つけるたびに追記する）
## このリポジトリの約束事
- 変更後は必ず ./scripts/screenshot.sh で表示を確認する
- テストは対象ファイルだけに絞って実行する（全体実行は遅い）
- 生成結果を鵜呑みにせず、性能値は手計測と突き合わせる

3. 検証ツールを .claude/commands にまとめる

氏のもう一つの手段は「実際にプログラムしたツール」。スクリーンショットや絞り込みテストの実行を、繰り返し使えるスラッシュコマンドにしておきます。

# .claude/commands/check.md
以下の順で検証してください。
1. ./scripts/screenshot.sh を実行して表示崩れがないか確認
2. $ARGUMENTS に関係するテストだけを実行
3. 問題があれば原因を特定して修正し、1 に戻る

4. 費用・稼働の目安を持つ

氏は非自明な機能を約16セッション・トークン費用 $15.98・実working約8時間で仕上げたと開示し、バックグラウンドエージェントを回せるのは「稼働日の10〜20%程度」と正直に述べています。誇張のない目安として、費用の可視化から始めるとよいでしょう。

# セッション中に費用と使用量の内訳を確認する
/cost