32 ポイント 投稿者 gracefullight 2026-03-16 | 4件のコメント | WhatsAppで共有

エージェントに「TODOアプリを作って」と言えば、何かしらは作ります。問題は、しばしば見当違いのものを作り、範囲を逸脱し、同じミスを繰り返すことです。

こうした問題を解決するため、初期にはAGENTS.md、最近ではSkillsのような構造的アプローチが数多く登場しました。ですが、実際に共有されているスキルを見ると、いくつか共通した問題があります。

  • 最も重要な ライブラリのバージョン情報が欠けている
  • 役割説明が "You are a Senior engineer" のような 宣言で終わっている
  • キーワード数個で十分な内容を 冗長に書いてトークンを浪費している

結果として、こうしたスキルはモデルがうまく従えず、コンテキストだけを無駄にしたまま、長期的には誰も開きたくないデッドコードになりがちです。


[アプローチ]

oh-my-agentでは、この問題をプロンプトではなくプロセスで解決したいと考えました。エージェントが仕事を誤ったとき、単に「もう一度やって」と言う代わりに、なぜ間違えたのかを記録し、次の実行に反映する構造を置いています。

代表的なメカニズムが Clarification Debt(CD) スコアリングです。エージェントが要件を誤解したり範囲を逸脱したりすると、点数が蓄積されます。

  • clarify: +10 — 単純な確認質問
  • correct: +25 — 意図の誤解による方向修正
  • redo: +40 — 範囲逸脱によるロールバック後の再開始
  • Charter確認なしで作業開始: +15
  • 許可範囲外のファイル修正: +20
  • 同じエラーの繰り返し: x1.5 multiplier

50点を超えるとRoot Cause Analysis(RCA)の作成が必須となり、80点を超えるとセッションは中断されます。ここで得られた教訓は lessons-learned.md に蓄積され、次のセッションからすぐに反映されます。プロンプトを簡潔に書いても、プロセスが補正してくれる構造です。

このほかにも、エージェントが勝手に動かないよう、いくつかの共通プロトコルを設けています。

  • Clarification Protocol
    要件の曖昧さを LOW / MEDIUM / HIGH に分けます。LOWなら進行、MEDIUMなら選択肢を提示、HIGHなら作業を止めて明確化します。
  • Difficulty Guide
    タスクを Simple / Medium / Complex に分け、必要なプロトコルの深さを調整します。
  • Context Budget
    モデルごとのトークン予算を設定し、不必要なコンテキスト浪費を減らします。

このようなアプローチは、OpenAIが述べた Harness Engineering にも通じています。エージェントをうまく使う問題は、プロンプト1行の問題ではなく、エージェントをどのような構造で制御するかの問題だという考えです。


[プロジェクト構造]

oh-my-agentは、これをプロジェクト構造の中で管理します。

  • .agents/ = SSOT
    スキル、ワークフロー、設定を .agents/ 配下に集約し、単一の信頼できる情報源として使います。特定のIDEには依存しません。
  • 役割ベースのエージェントチーム
    PM、QA、Frontend、Backend、Mobile、Debug といった基本役割に加え、今回DB AgentとTF Infra Agentが追加されました。
    • DB Agent: SQL / NoSQL / Vector DB モデリング、ISO 27001 セキュリティ推奨を含む
    • TF Infra Agent: マルチクラウドTerraform、OPA / Sentinel ポリシー、ISO 42000シリーズの統制ガイドを含む
  • ワークフロー中心のオーケストレーション
    計画、レビュー、デバッグ、並列実行を基本フローとしています。新たに追加された /brainstorm ワークフローは、コードを書かずに設計から探索します。
    コードベース分析 → 明確化質問 → アプローチ提案 → ユーザー承認 → 設計文書保存の順で進め、その後 /plan → 実装 へとつながります。

[2つのオーケストレーションモード]

/coordinate は、素早く回して問題が出たら修正する方式です。PMがタスクを分解してエージェントを実行し、その後QAが1回レビューします。CRITICAL/HIGH の問題が出た場合は該当作業を再実行する構造で、全体として軽量かつ高速な 7段階ループ です。

一方 /ultrawork は品質検証を強く重視します。PLAN → IMPL → VERIFY → REFINE → SHIP の5段階に分かれ、各段階にゲートがあり、通過できなければ次の段階へ進めません。17段階のうち11段階がレビューであり、REFINE 段階ではファイル分割、重複除去、副作用分析、dead code の整理まで行います。

少しやり過ぎに見えるかもしれませんが、機械語 → プログラミング言語 → 自然言語とプログラミングの抽象化レベルが高くなるほど、結局は検証が最も重要になる、という点には共感していただけると思います。


[プロジェクト拡張の背景]

1か月前には oh-my-ag というAntigravity専用オーケストレーターとして紹介していました。しかしその間に、複数のAI IDEが .agents/skills/ をプロジェクトスキルのパスとして使い始め、特定IDE専用にしておく理由がなくなりました。そこで汎用ハーネスの形へ拡張し、oh-my-agent になりました。


[始め方]

curl -fsSL https://raw.githubusercontent.com/first-fluke/oh-my-agent/… | bash

Antigravity、Claude Code、Codex CLI、Cursor など主要なAI IDEをすべてサポートしています。


すでにAI IDEを使っているなら、一度試してみてもよいと思います。結局のところ、開発者の目標は QCD (Quality, Cost, Delivery) を同時に実現することです。エージェント開発も例外ではない、という考えで作られています。

🔗 GitHub: first-fluke/oh-my-agent

4件のコメント

 
findme 2026-03-16

以前から使っていたユーザーなので、うれしい知らせですね。coordinate を満足して使っていました。
ちょうど、もっと検証できるといいなと思っていたところでしたが、ウルトラモードはさらに綿密だとのことなので、明日さっそく使ってみようと思います。

 
gracefullight 2026-03-16

ありがとうございます! もしあまり言うことを聞かなければ、教えてください。

 
moon5g 2026-03-17

package.json でスクリプトを追加していたら、ワークスペースフォルダだけ残して他のファイルを全部削除してしまうんですね。復旧中ではあるんですが、あっけにとられますね。

 
gracefullight 2026-03-17

Claude やエージェントの内部で実行されましたか? package.json やすべてのファイルを削除するコードはないはずなので。フロー全体を教えていただけると助かります!

  • tarball.ts:33,35,43 — /tmp/oh-my-agent-* 一時ディレクトリのみを削除
  • cleanup.ts:108,231 — PID ファイル、明示的な oma cleanup コマンドでのみ実行
  • agent.ts:665,1027 — PID/ログファイル(プロセス終了時)
  • skills.ts:234 — .cursor/skills 内のシンボリックリンク 1 個
  • migrate.ts:45-80 — レガシー .cursor/skills シンボリックリンクディレクトリ