YAGNI

YAGNI

YAGNI · 生産性向上

YAGNIは、プロアクティブなAIエージェントチームをエンジニアを管理するのと同じやり方で管理するためのワークスペースだ。各ワーカーには定められた職務、単一のパフォーマンス指標、期限付きのコミットメント、そして承認と証憑を伴うレビューのループがある。だから影響の大きいものは、人の同意なしに出荷されない。すでにバックログを運用していて、AIコーディングエージェントにチケットを提案からマージ済みのpull requestまで運ばせたいAIソフトウェア開発チームに向いている。

YAGNI の画面プレビュー

YAGNI について

YAGNIとは何か

YAGNIは、シンプルな前提の上に築かれたエージェントのワークスペースだ。AIワーカーは、道具のようにプロンプトで動かすよりも、人として管理したほうがよく働く。各ワーカーは訓練段階から始まり、名前の付いた責任を担い、共有の記録に報告する。記録こそが要点だ。提案、計画、ビルド、レビュー、テスト、そして各実行のコストはすべて同じ場所に集まり、人がゲートに答える。

このプラットフォームは関連する2つの仕事を扱う。1つは、名前を持つ6人のワーカーのチームで、チケットをマージ済みのpull requestまで運ぶ。もう1つは、同種のフロンティアAPI料金を大きく下回る価格のAIコーディングエージェントだ。どちらも同じ検証済みで米国でホストされるオープンウェイトのモデルで動き、同じ意思決定の台帳に書き込み、同じメーターで課金される。

主な制約は運用モデルそのものにある。YAGNIは、JiraかLinearにバックログがあり、紐づけるリポジトリがあり、承認ゲートに答える意思のある人がいることを前提とする。コードをただ押し出すだけの全自動ボットが欲しいなら、これは必要以上の構造だ。マージはどの自律レベルでも常に人に残る。これは設計上のものだ。

はじめかた

  1. 創業者との30分の通話を予約し、リポジトリとバックログを持参する。請求書のほうが気になるなら利用状況のエクスポートを持参する。
  2. チームを既存のリポジトリ、Playbook、予算に接続し、各ワーカーが担う責任を設定する。
  3. JiraかLinearからバックログを紐づけ、Product Managerワーカーが証拠を添えて次の項目を提案できるようにする。
  4. 提案を確認し、計画を承認し、ビルダーにクラウドサンドボックス内のpull requestまで運ばせる。
  5. レビューゲートに答え、テスト動画を見て、記録が信頼に値するときにマージする。それに応じてゲートを緩める。

AIツール情報

YAGNIの料金、対応プラットフォーム、性能を簡単に確認できます。

無料プランいいえ
有料プランUsage-based, about 60% below comparable frontier API rates
プラットフォームWeb app, Jira, Linear, Slack
開発元YAGNI
カテゴリ生産性向上
リリース日Sep 2025
最終更新Sep 2025
サイト訪問数2.2K
サイト世界ランキング9M
API提供状況N/A

こんな人におすすめ

このツールが最も力を発揮するユーザー、タスク、シーン。

ユーザー

  • すでにバックログを運用していて、使い捨てのコード片ではなく、エージェントにチケットをpull requestまで運ばせたいエンジニアリングマネージャー。
  • すべてのpull requestにレビューの網羅性を求めつつ、定型の変更に専任レビュアーを割けない小規模なプロダクトチーム。
  • より安いAIコーディングエージェントとフロンティアツールを天秤にかける個人開発者。チームモデルがバックログとリポジトリを前提とする点は頭に入れておきたい。
  • 中規模企業の財務・セキュリティ責任者。エージェントにアクセスを許す前に、範囲を絞った資格情報、求めに応じたDPA、ワーカーごとの支出上限を必要とする。

タスク

  • バックログの項目をレビュー済みのpull requestに変える。Product Managerが作業を提案し、Staff Engineerが計画を批評し、BuilderがPRを開き、人がマージする。
  • 変更ごとのブラウザベースのQA。QAワーカーがアプリをサンドボックスで起動し、判定を添えたスクリーンショットと動画を付ける。
  • 週次のレポート。ChroniclerワーカーがBriefとSlackのスタンドアップを作り、出荷したものと人の対応がまだ必要なものをまとめる。

シーン

  • 小さく低リスクなpull requestで溢れているのに、マージ前にやはり目を通す必要があるチーム。
  • 反復的な定型のコーディング作業を従量課金のエージェントに置き換えつつ、判断が要る場面は人に残す。
  • スプリント全体でエージェントが実際に何をしたかを、提案・レビュー・コストの記録としてのケースファイルで監査する。

主な機能

境界を持つ6人の名前付きワーカー

YAGNIは仕事を6つの役割に分ける。それぞれに定められた上限がある。Baileyは次に来るものを提案する。Reeveは計画を批評する。Wrightはpull requestまでビルドする。ProctorはすべてのPRをレビューする。FletcherはブラウザQAを実行する。Harperは起きたことを報告する。境界は職務と同じくらい重要だ。Wrightは決してマージせず、Proctorは決してマージを妨げず、Harperは一切行動しない。

作業項目ごとに1つのケースファイル

各作業項目は1つのページで、提案、計画、各実行、pull request、レビュー、テストの証拠、人が答えたゲート、総コストを収める。意思決定は散らばったスレッドではなく、そのページで決着する。そこへのコメントは計画の1行かPlaybookの新しいルールになる。エージェントが予想外のことをしたとき、その理由が分かるのはここだ。

自分で制御する自律のはしご

各チームは訓練段階から始まり、すべてのステップが人を待つ。記録が解決済みの意思決定で埋まるにつれ、エンゲージメントを1段上げると、自分で扱う権利を得た事柄については尋ねなくなる。マージはどの段でも人に残る。したがって最高レベルの自律も、監督された自律だ。

1つの料金表、4つのレーン

設定の通話を終えれば、ワーカーと開発者は同じメーターを共有する。ルーターは各ステップを実行前に見積もり、品質を保てる最も安いレーンに置く。だから定型的な読み取りが最高料金を払うことはない。席なし。プラットフォーム料金なし。ワーカーごとの課金なし。各実行は走りながらコストを出力する。

リポジトリとバックログの直接統合

チームは単一のリポジトリではなく、あなたのエンジニアリングチームの1つを写し取る。自前のリポジトリ、Playbook、予算、そして責任を負う1人を持つ。ワーカーはJiraかLinearからバックログを読み、Slackに報告する。だからすでに使っているツールはそのまま残る。提案段階でSlackのプロダクトマネージャーにメンションすれば、その返答は作業が始まる前に計画へ入る。

範囲を絞った暗号化された資格情報

コネクタの資格情報は顧客ごとに範囲が切られ、暗号化される。既定のアクセスは想像より狭い。あるエンゲージメントでは、1人のワーカーがWebアプリで承認できても、インフラのリポジトリでは助言だけに留められる。こうして広い権限が機密のリポジトリに漏れ出すのを防ぐ。

メリットとデメリット

メリット

  • 明確な役割の境界が各エージェントを単一の職務に保つ。だから汎用アシスタント1つよりも、失敗の追跡が容易だ。
  • ケースファイルが、何が走り、いくらかかり、誰が承認したかの監査可能な証拠を与える。
  • ワーカーごと・日ごとの上限を伴う従量課金が支出を予測可能にし、人の読み手に席あたりの課金はない。
  • 意味のあるゲートはすべて人に残る。だから導入初日からエージェントを無監督で信頼する必要はない。

デメリット

  • 無料プランがなく、料金は公開ページではなく商談で決まる。だから会社に先に聞かないとコストを見積もれない。
  • 構造化されたモデルが既存のバックログとリポジトリを前提とする。だからそのワークフローのない個人ユーザーやチームには向かない。
  • APIの可用性が公開文書化されていない。だからプラットフォームがプログラムからのアクセスを提供するかはサイトから判断できない。

よくある質問

6人のAIエージェントチームワーカーのチームを動かし、ソフトウェアのチケットをバックログからマージ済みのpull requestまで運ぶ。人が計画を承認し、結果をレビューする。これと並んで、同じプラットフォームが個人のエンジニア向けに従量課金のコーディングエージェントを提供する。