💡 本投稿は 100% 人間が書きました。
まとめ
- XユーザーのRebuild Podcastさん: 「Rebuild: Waterfall But Really Fast (obra)」 / X がとても興味深かった。面白かったので読むのをオススメ。
- 自分が Superpowers にどっぷり浸かっているからというのもあって。
- AI業界のソートリーダー（思想的指導者）の一人の考えが知れて勉強になる。
はじめに
ハーネスエンジニアリング、定義はブレがあるが、自分の中では生成AIに何かを被せて入力に対する出力の方向を定めるもの、そしてそれはスキルで実現できる、スキルを組み合わせることで開発の流れを作っている、「何かを被せて」は、マイクロマネジメントの側面があるもの、というイメージです。
ある時 obra/superpowers: An agentic skills framework & software development methodology that works. を見つけその考えを知り、その当時 Gemini CLI に未対応だったので obra/superpowersスキル移植と日本語化とオリジナルスキルを少し足したもの を作ってきました。その過程で、上記の考え方はより深まっています。
個人的には、それはソフトウェアエンジニアリング界で信頼できそうな人の持ち物なので、 obra/superpowers: An agentic skills framework & software development methodology that works. は今のところセキュリティ的に信頼できると思っています。
ある日のこと
X.com のおすすめのトップがなんとなく目に入った。
XユーザーのRebuild Podcastさん: 「Rebuild: Waterfall But Really Fast (obra)」 / X
GitHub で16万以上のスターを獲得しているエージェントスキルフレームワーク superpowers の作者であり、長年の友人でもある Jesse Vincent (obra) をゲストに迎えて Rebuild ep424 を収録しました。日本語字幕つきの動画も YouTube で公開しています。 #rebuildfm
びっくりした。興味を持ち、移植していたスキルの作者が、いつも聞いているポッドキャストのホストと友人だったとは。
ポッドキャスト本体を聞いてもよくわからず、英語のトランスクリプトもよく分からず、でも、先ほどの X の投稿は日本語なので、それを読んだ。
以下、個人的に響いた箇所を引用します。
jesse: 毎月変わっています。ツールはすべて良くなっていますが、問題を分解する必要があるのは変わらないですし、ほとんどのツールが「頼まれたこと」を実行してしまうのも同じです。問題は、大抵の場合、人間側が「自分が必要なもの」を頼むのがすごく下手だということですね。深く考えずに、自分が欲しいと思い込んでいるものを頼んでしまうんです。
jesse: AIを使うのが上手な人に共通しているのは、自分が何を望んでいるかを考え、開始する前にそれを明確に説明できるという、マネジメントの経験があることだと思います。Claude Codeを開いて「ReactでToDoリストを作って」と言うのと、まず立ち止まって「なぜそれを作りたいのか？目的は何なのか？」を説明することの違いですね。
どこかで説明する能力がより重要になってくる、というのをネットで見た記憶がある。トップランナー、リーダーたちは大体こういったことを言うので、そうなんだろうなと思う。自分も移植の体験を通して、そう思う。
jesse: ただ、これが永遠に続く正しい構築方法だとは思いません。僕は最近、Superpowersのような「事前になんでも計画する」スタイルではなく、イテレーティブ（反復的）な開発のための新しいスキルセットを試しています。
jesse: 僕の経験では、Superpowersのプランは30KBから40KBくらいになると、うまく実行できるか不安になります。でも新しいツールを使えば、600KBもの仕様書を読み込ませても、要件を漏らすことなくアプリを生成できています。
Superpowers のさらに先があるのか。そりゃそうだろうと言われればそうかと思うが、速い。一方自分は、そもそも Gemini CLI を使い出したのは、無料で使いたかったからで、無料で使おうとするとセッションの長さを短くしようとするので、こんなことは全く思いつきもしなかった。
jesse: そう思います。元のコードの質にもよりますが。反復開発スキルを調整してきた中で分かったのは、初期のツールは「テストのしやすさ」を重視しすぎて、APIの境界が多すぎたんですね。テストが元の10倍くらいあったので、コードが少し複雑になっていました。ただ、何年もかけて作られた古いコードベースの場合、こちらの方が良いコードを生成できる気がします。エージェント開発に詳しい友人たちが発見したのは、エージェントを使って「ソースからソースへ」移植する際、特定の特性を持つ言語を経由させることで、コードベースの質を向上させられるということです。JavaScriptやRuby、PythonのコードをRustに移植させ、そこからまた別の言語に移植させます。Rustを経由することで、最終的に出来上がるコードの型安全性が向上するんです。普通ならAからB、BからCへ移植すれば伝言ゲームのように質が落ちるはずですが、友人たちは逆に、移植するたびにコードが洗練され、クリーンアップされ、経由した言語の良い性質を吸収していくと言っています。
miyagawa: Rustの場合なら、型安全性が増したり、パターンマッチングのような表現力のおかげで簡潔になったりする、ということでしょうか。
jesse: そうです。 …略…
面白い！型厳格な言語を挟むことで質が向上。と言うことは、元のソースコードを単純にブラッシュアップするために、元の言語 → 例えば Rust → 元の言語、と移植すると良いのでは？
miyagawa: ええ。自分専用のソフトで簡単に再現できてしまうツールですね。例えば名前は出しませんが、スクラムボット。Slackボットがチーム全員に「昨日何をした？」「今日は何をする？」と聞いて、結果を別のチャンネルに集約して共有するようなものです。もちろん、履歴を保持したりチーム間のプライバシー設定をしたりといった、お金を払う価値のある側面もありますが、機能の99%は簡単に複製できてしまいますし、強力な堀もありません。
jesse: その例で言えば、僕が会社のSlack用に作ったボットは最初、2つの目的を持っていました。1つは事実を学んだらWiki（Gitリポジトリ）を更新すること、もう1つは誰かが問題を口にしたらLinearのチケットを発行することです。ある時、デイリースタンドアップをやっていることに気づき、ボットにこう教えました。「デイリースタンドアップのチャンネルを注視して、誰かが報告したら記録しておいて。次にその人が投稿したときに、前回の内容を引用して『どうでしたか？』と聞いて」と。ただのプロンプトです。それだけでボットが機能するようになりました。面白いのは、投資家の一人が僕と個別のSlackチャンネルにいるんですが、メモを取らせるためにそのボットを招待したんです。すると彼は、チームが何をしているか、ボットが今の作業をどう捉えているかを質問できることに気づきました。中身はただのClaudeですから、作るのも簡単でした。ニュース記事を要約させて、それが今の自分たちの仕事にどう影響するかを聞いたりしています。ボットがすべての情報を持っているのを見て彼が対話している様子は、本当に面白いですよ。
jesse: エージェントから最高の結果を引き出す方法は、自分の望みをはっきり伝えること、あるいは変なことが起きた時に止めて「なぜそうしたのか？何を考えていたのか？どう言えば正しく伝わったと思う？」と聞くことです。そして会話を巻き戻し（rewind）、エージェント自身が提案した「より良い伝え方」で最初からやり直すんです。
単純に、こういったことは業務改善のアイデアとして使えそうと思った。
jesse: これについてはブログにも書きましたが、MCPを「APIのファサード（窓口）」だと考えると失敗します。MCPを使う存在は人間により近いので、どちらかというと「UNIXコマンド」を作る感覚で設計したほうがうまくいきます。Fastmailを読むエージェントを作ったとき、既存のJMAP（JavaScriptのメールプロトコル）用MCPを使わせましたが、メッセージ1つダウンロードするのにも苦労していました。JMAP MCPがプロトコルを忠実に再現しすぎていたからです。そこでボットに「僕のブログの『なぜMCPは他のAPIとは違うのか』という記事を読んでこい」と言いました。戻ってきたClaudeは「あ、理解しました」と言いました。「良いMCPは、深夜2時にNOC（ネットワークセンター）で働いている新人が、手順書を開かずに操作できるものであるべきだ」と。僕の言い回しとは少し違いますが、間違っていません。今ではMCPを設計するときは、Claudeに僕のブログを読ませて「良いMCPを書くための禅」を理解させるようにしています。
よく分からない、ピンと来なかった(自分が MCP について腹落ちしていないので)が、なんか重要そうと思った。
おわりに
久しぶりに、繋がった感覚を感じました。
以上です。