環境面

基本

• インターフェイス: roo code 一択。
• モデル: sonnet/gemini/llama4 あたりを適当に。api ratelimit を目安に切り替え。
• サービス: 仕事ではclaude/geminiのいずれか。個人では何でも使う。gemini 2.5 pro(exp) あたりから全体的にgeminiをよく使うようになったかも。

個人ではgrokもよく使う。鮮度が求められる調べ物に関してはツイッターを検索対象に入れられる点がでかい。あとllama4もだいぶよい、個人でsonnet/geminiなりがratelimitにかかったときにたまに使う程度だが、別に普段遣いでも問題ない印象。

MCP

think mcp

• 自作mcp。消費するコンテキストの少なさの割に確かに出力精度が安定する気がするので高頻度で使ってる
• 後述のユースケースに合わせてシステムプロンプトを少しいじっている

github mcp server

• コードベースに関する浅い調べ物をするときにかなり重宝する。
• 利用しているOSSに関する挙動で気になるところがでてきたらソースコードを読む癖があるが、これのおかげでリーディングの負担が激減した。
• より細かくファイルを特定した調査をしたいときや手元で自分でもなにかしたいときは普通にcloneして諸々開き直す

aws docs server

• これのおかげでawsサポートケース利用率が激減した。超絶便利。なにより応答が爆速なのが最高。
• bottlerocketをよくいじるのだが、これにgithub mcpを加えて色々調査指示を出すとたいぶ捗った。

mcp script runner

• 自作mcp。任意のファイルのstdoutをtool responseにできるのが便利。
• .env対応したのでcredentialをexportしておけばcliも使えるようにしてある。書き込み権限があるかどうかはcredential次第なのと出力はツールとして使ったファイルの書き方次第なので制御しやすいのが気に入ってる。

ユースケース別

Research

• 個人用途での初手はgrok一択。不確実性が高いネタや情報鮮度が重要なことが多く、ツイッターが検索対象に入ってる点がデカイ。
• Deep Researchはときどき使うけどperplexity無料枠で収まる程度しか使わない。geminiのよりperplexityのほうが一歩踏み込んだ回答をしてくれる印象。geminiは検索結果を小綺麗にまとめただけって感じでイマイチ。モデルが強くなったらまた変わるのかも。

Architect

• 仕事ではResearch的なことをすることは少なく、awsに関する調べ物が多いのでこちらから入る事が多い。
• roomodesは特に使わずデフォルト設定まま使ってる。
• 設計だけでなくaws docsやgithubを対象とした調査でもAskではなくArchitectで行う。結局最後にはコード・コマンド・プランを出力してほしくなるし、いちいち切り替えるのがだるい。
• バイアスがない方が良いことが多いのでルールファイルは基本空っぽで。
• think mcpをなるべく都度挟ませて横道にそれたりを抑制、出力を安定させる。Architect向けに少しシステムプロンプトをいじったtoolを使わせる。
• mermaidはコンテキスト消費のわりに意味がないので出させないことが多い。出力させるのは他人に見せるときのdocsを書くときくらい。

Code

• 純粋関数を書かせるなど単用途でなるべく都度新規セッションで作業を開始させる。
• セッション内の範囲では自動承認で色々作業をさせてよい。
• sonnetはコンテキスト小さめなのでstdout/stderr食わせる系の作業のときはsonnet以外を選ぶほうが無難だが、適切にプロンプト指示ができていればコンテキストが溢れる前に仕事を終わらせられる事が多い。stdout/stderrを食わせる系の状態に如何に行かせないかのハンドリング・状況理解力・指示力が重要。
• TDDっぽく先にテストを書きたいが既存コードの修正系だとそうもいかないので無理にTDDはさせない。
• 結合テストも込みでやらせると急激にコンテキストが肥大化していくので注意。テスト自体は自分でやって内容確認しつつ次のプロンプトをいい感じに書いてあげる、というほうがコンテキスト消費が小さく出力の質も下がりにくくなり、体験も良くなる。
• think mcpを使わせる場合はCoder向けに少しシステムプロンプトをいじったtoolを使わせる。が不確実性が低くやることが明確なものについては使わせないことも多い。別mcpを確定で使う予定の場合などコンテキストがこれからまだ大きくなりそうな段階で、出力を安定させるために呼んだりする。

禁止事項

• 丸一日放置とかの丸投げ系vibe codingは時間と資源の浪費なのでNG
  • コンテキストが肥大化すると出力が急激にハルシネーションを起こしたり同じコマンドで無限ループしたりして最終的にコンテキストが溢れて死ぬため。金はともかく時間かけた割にコードの質が置きざりというのがしんどい。にも関わらずコード量はかなりのものになったりして、直して依頼し直すにしても巨大な技術的負債を押し付けられた気がして、つらい。突然退職した人の案件を引き継ぎなしで押し付けられたとかクソコードの尻拭いをさせられているといった気分になり、精神衛生上非常に良くない。
  • コーディングの項にも書いたができるだけ細かく依頼をし直すことが現状の最善手。
• ルールファイル書き過ぎはNG
  • なるべく書かないか、空っぽ。極端な思想だとは思うがコンテキストが小さい序盤のボーナスタイムを長めに過ごせる、と思っている。巨大なrailsのコーディングルールとか似た要求を恒常的に依頼するなら作り込んでもよい。が、個人的にやること・やってることの要件や要求・プロジェクトの場所が異なることが多いので作り込んでもコンテキスト消費するし、ルールのメンテコストはサイズに比例するしで、大きくするとリターンが薄まるという印象を持っている。

今後やりたいこと

• より厳格なTDDモード: ルールファイルだけではどうしてもコンテキストが肥大化したり油断してると先にコード書いてそのあとテスト書いたりとかしがちでTDDにならない、のでより厳格にTDDさせたい。なるべくコンテキストが肥大化する前に終わらせるか TDD-Architect をやってから TDD-Code に入るというようにセッションを分けたほうが良いかもしれない。
• roomodesで巡回: まずTDDがちゃんと回せるようになって身体が、TDD→Code→TDD→…のように巡回させてコンテキスト肥大化を抑えつつ出力精度が低くなりづらいvibeっぽいことがしたい。うまくいけば丸投げできる可能性が広がる。roomodesはサブタスクごとにコンテキストが別なようなので理屈上はいけるはずだが、少し触った感じ挙動が安定しなかったのでどうしたもんか悩み中。
• ルールファイル関係のmcp化: mcpを通すと軒並み質が下がりにくくなる気がしてる。逆に言うとルールやプロンプトでコンテキストにいれても出力したログのうち手前（直近に出力したもの）の内容に強く引っ張られる挙動をしているように見受けられる。だからthink mcpが一定の効果があるのではないか、と感じている。なのでルールファイルというかmemory bankというか、そういうものをグローバルにひとつ、プロジェクトにそれぞれひとつ、という感じで持たせたい。RAGよりはテキストベースのほうが効きが良いような気がするので、テキストベースで。