Kirat - Multi Model AI Council

公式

一つのAIは一つの推論しか示さない。KiratはClaude Desktop拡張機能およびClaude Codeプラグインで、ChatGPTとGeminiを評議会として追加する：独立した立場、反対意見を保持した投票、そして各指摘が第二のモデルファミリーによって検証されるコードレビュー。独自のAPIキーを使用する。有料、一回限り。

kirat.ai で表示

Kirat Multi Model AI Council MCPで何ができますか？

  • 複数モデルによる意思決定の投票を得る — kirat_vote に依頼して、選択肢と文脈を添えたビジネスまたは技術的な質問について、カウンシルの意見を聞きます。
  • セキュリティと正確性のためのコードレビュー — リリース前に kirat_review を使用して、重大度レベルと提案された修正を含むクロスチェック済みの所見を取得します。
  • 決定に対する反対意見とその根拠を確認する — 少数派の投票を含む各モデルの完全な立場を、信頼度スコアと根拠とともに取得します。

ドキュメント

01 — リプレイ

評議会の働きを見る。

購入するバージョンを使って2026年10月13日に記録された、Kiratのツールの実際の録画です。ツールを選んで、評議会の働きを見てください：独立した立場、相互チェック、匿名ランキング、そして反対意見。これはリプレイです。ここでクリックしてもモデルは呼び出されず、このページから何も送信されません。チャットは説明用に書かれており、記録された結果を言い換えているだけです。ClaudeがKiratに送ったものと、返ってきたものは、「舞台裏」の下に変更なしで表示されます。

さまざまな分野からの5つの質問。1つ選んでください。

Kiratに投票させましょう：私は小さなB2B SaaSを一人で運営しています。無料プランを追加すべきでしょうか？

kirat_vote が評議会に質問しました

評議会は決定しました（多数決2:1）：有料のみを維持し、何も変更しない。

私自身の投票は反対意見でした：「有料のみを維持し、トライアルを30日に延長」。その理由とともに記録に残っているので、ご自身で判断できます。

舞台裏

kirat_vote ClaudeがKiratに送るもの

質問： 私は小さなB2B SaaSを一人で運営しています。無料プランを追加すべきでしょうか？

記録日 2026-10-13 · KIRAT_VOTE · 労力：標準 · 1ラウンド

送信されたコンテキスト： 個人開発者。フリーランサー向け請求ツール、月額19米ドル、14日間の無料トライアル、5か月後に有料顧客30名。サインアップは主にGoogleで上位表示されている2つのブログ記事から来ています。トライアルの約12%が成約しています。サポートはすでに週に約5時間かかっています。開発者は本業があり、製品に使える時間は週に約10時間です。

選択肢： 無料プランを追加する · 有料のみを維持し、トライアルを30日に延長する · 有料のみを維持し、何も変更しない

評議会の結果

gpt-5.6 信頼度 88

有料のみを維持し、何も変更しない無料プランは、非課金ユーザーとサポート負荷を増やす可能性が高く、サポート負荷はすでに週10時間の半分を消費しています。12%のトライアル成約率は立派なので、トライアル期間がボトルネックであるという明確な証拠はありません。現在のモデルを維持し、限られた時間をサポートニーズの削減と、2つのブログ記事以外の集客拡大に充ててください。

gemini-3.6-flash 信頼度 90

有料のみを維持し、何も変更しない週に10時間しかない中で、サポートはすでに容量の50%を占めています。無料プランは、非課金ユーザーからのサポート量を制御不能な形で増やすでしょう。12%のトライアル成約率はすでに強力です。ボトルネックは価格モデルではなく、トラフィックです。

claude（第3投票者） 信頼度 58

有料のみを維持し、トライアルを30日に延長する無料プランは主にサポート負荷を増やしますが、それはすでに利用可能な時間の半分です。請求は月単位なので、14日間のトライアルは、フリーランサーが2通目の請求書を送って価値を実感する前に終わってしまうかもしれません。30日間のトライアルは、恒久的な無料ユーザーを増やさずに、1回の完全な請求サイクルをカバーします。反対意見、記録済み

決定 有料のみを維持し、何も変更しない 経路 多数決2:1 コスト $0.015

Kiratに投票させましょう：クライアントのオンラインショップをリビルドする必要があります。WooCommerceでリビルドするか、Shopifyに移行するか？

kirat_vote が評議会に質問しました

評議会は決定しました（全会一致3:0）：Shopifyに移行。

私のものを含む3つの立場すべてが同じ方向を指しています。それぞれに理由が付いています。

舞台裏

kirat_vote ClaudeがKiratに送るもの

質問： クライアントのオンラインショップをリビルドする必要があります。WooCommerceでリビルドするか、Shopifyに移行するか？

記録日 2026-10-13 · KIRAT_VOTE · 労力：標準 · 1ラウンド

送信されたコンテキスト： 私たちは小さなデジタルエージェンシーです。クライアントはドイツ、オーストリア、スイスで約1,800の家具製品を販売しており、従業員は3名、社内開発者はいません。現在のショップはセルフホストのWooCommerceインストールで、6年前のもので、プラグインが31個、ページが遅く、過去1年間に2件のセキュリティインシデントがあります。売上は年間約120万ユーロです。クライアントはメンテナンスの削減と緊急事態の減少を望んでいます。彼らは製品データをCSVでエクスポートするローカルERPを使用しています。リビルドの予算：25,000ユーロ。

選択肢： WooCommerceでリビルドする · Shopifyに移行する

評議会の結果

gpt-5.6 信頼度 89

Shopifyに移行するShopifyは、クライアントの主要な目標（メンテナンスの削減、セキュリティ緊急事態の減少、社内開発者が不要）により適合します。1,800製品のカタログとCSVベースのERPワークフローは管理可能であり、25,000ユーロの予算で、規律ある移行とDACH固有の税務、決済、法務設定をカバーできるはずです。トレードオフは、継続的なアプリ/プラットフォームコスト、バックエンドの柔軟性の低下、そしてERPインポートワークフローと家具固有のバリアントをコミット前に検証する必要があることです。WooCommerceのリビルドは柔軟性を維持できるかもしれませんが、ホスティング、アップデート、プラグイン互換性、セキュリティの責任を保持することになり、これはクライアントが削減したいまさにその運用上の負担です。

gemini-3.6-flash 信頼度 90

Shopifyに移行する社内開発者がおらず、従業員3名、セキュリティインシデントの履歴があるため、Shopifyはメンテナンスのオーバーヘッドとセキュリティリスクを大幅に削減します。25,000ユーロの予算は、CSV ERP統合を含むShopify移行には十分ですが、WooCommerceでのリビルドは高いメンテナンスコストと継続的な緊急リスクを永続させるでしょう。

claude（第3投票者） 信頼度 72

Shopifyに移行する社内開発者がおらず、プラグインが31個、セキュリティインシデントが2件あるため、クライアントの本当の問題は機能ではなくメンテナンスです。Shopifyはホスティング、アップデート、ほとんどのセキュリティ作業を排除します。ERPからのCSV製品インポートは標準的です。トレードオフは取引手数料とアプリ料金、そして柔軟性の低下ですが、この規模では安定性ほど重要ではありません。

決定 Shopifyに移行する 経路 全会一致3:0 コスト $0.015

Kiratに投票させましょう：地元のベーカリーがケーキの予約注文を増やしたいと考えています。次の3,000ユーロはどこに最初に使うべきでしょうか？

kirat_vote が評議会に質問しました

評議会は決定しました（全会一致3:0）：適切なオンライン注文ページ。

私のものを含む3つの立場すべてが同じ方向を指しています。それぞれに理由が付いています。

舞台裏

kirat_vote ClaudeがKiratに送るもの

質問： 地元のベーカリーがケーキの予約注文を増やしたいと考えています。次の3,000ユーロはどこに最初に使うべきでしょうか？

記録日 2026-10-13 · KIRAT_VOTE · 労力：標準 · 1ラウンド

送信されたコンテキスト： 人口4万人のドイツの町にある、従業員6名のベーカリー。カスタムケーキと予約注文が最も利益率が高いです。現在、注文は電話とメールのみで受け付けています。ウェブサイトには営業時間と問い合わせフォームがあるだけで、注文できるものはありません。Googleビジネスプロフィールは、120件のレビューで4.7星です。これまでの有料広告はありません。予算：次の四半期に3,000ユーロ、オーナーは時間がほとんどありません。

選択肢： Google広告 · 適切なオンライン注文ページ · 両方に均等に分割

評議会の結果

gpt-5.6 信頼度 94

適切なオンライン注文ページまずボトルネックを修正してください：現在、興味のある顧客は便利に、または構造化された方法で予約注文できません。ケーキの選択、受け取り日、カスタマイズオプション、価格またはデポジット、確認を含む、シンプルでモバイルフレンドリーな注文ページは、ベーカリーがすでに持っている強力なローカルでの認知度を活用し、電話とメールの作業を削減します。信頼できる注文プロセスなしにGoogle広告を出すと、有料トラフィックが弱いコンバージョンパスに送られることになります。数週間の測定可能な注文の後、後の広告予算はよりターゲットを絞って使うことができます。

gemini-3.6-flash 信頼度 90

適切なオンライン注文ページデジタルでの注文経路がなければ、広告は電話とメールによる時間のかかる手作業を増やすだけで、オーナーはそれをほとんど処理できません。さらに、強力なGoogleプロフィール（4.7星）は、実際の注文ページがあれば、すでに集めているオーガニックトラフィックをはるかに良くコンバージョンします。広告に資金を投入する前に、すぐにです。

claude（第3投票者） 信頼度 74

適切なオンライン注文ページ広告は、クリックが注文につながる場合にのみ効果があります。現在、すべての訪問者は電話かメールをしなければならないため、有料トラフィックは漏れます。製品の選択肢、受け取り日、前払いを備えた注文ページは、4.7星プロフィールがすでにもたらしている需要をコンバージョンし、後の広告を測定可能にします。

決定 適切なオンライン注文ページ 経路 全会一致3:0 コスト $0.012

Kiratに投票させましょう：請求モジュールを今すぐ別のサービスに抽出するか、まずモノリス内でその境界を強化するか？

kirat_vote が評議会に質問しました

評議会は決定しました（全会一致3:0）：まずモノリス内で境界を強化する。

私のものを含む3つの立場すべてが同じ方向を指しています。それぞれに理由が付いています。

舞台裏

kirat_vote ClaudeがKiratに送るもの

質問： 請求モジュールを今すぐ別のサービスに抽出するか、まずモノリス内でその境界を強化するか？

記録日 2026-10-13 · KIRAT_VOTE · 労力：標準 · 1ラウンド

送信されたコンテキスト： 8人のエンジニアのチーム。1つのTypeScriptモノリス、約60,000行、1つのPostgresデータベース、1日に数回デプロイ。請求モジュールは毎週変更され、過去8件の本番インシデントのうち5件を引き起こしました。そのほとんどは、他のモジュールが請求テーブルを直接読み書きしたことによるものです。チーム内で分散システムを本番運用した経験がある人はいません。リーダーシップは2四半期以内にインシデントを減らしたいと考えています。

選択肢： 請求を今すぐサービスに抽出する · まずモノリス内で境界を強化する

評議会の結果

gpt-5.6 信頼度 94

まずモノリス内で境界を強化するインシデントの主な原因は、ネットワーク境界の欠如ではなく、制御されていないデータベースアクセスです。モノリス内で請求の所有権を強制してください：直接のテーブルアクセスを削除し、狭い内部APIを公開し、データベース権限またはスキーマレベルの制御を追加し、契約テストと統合テストを追加します。これにより、2四半期の期間内に障害モードを迅速にターゲットにできます。今すぐ抽出すると、分散システムの経験がないチームに、デプロイ、可観測性、リトライ、データ整合性、運用の複雑さが追加されます。アクセスパスとデータ所有権が明確になったら、抽出はより安全になり、独立したスケーリングやデプロイが依然として価値がある場合は再検討できます。

gemini-3.6-flash 信頼度 90

まずモノリス内で境界を強化する停止の主な原因は、他のモジュールがデータベース内の請求テーブルに直接アクセスしていることです。モジュール境界の強化は、既存のモノリス内でこの問題を直接解決します。8人のチームには分散システムの経験がないため、今すぐモジュールを抽出すると新たなリスクが生まれ、2四半期以内にインシデントを減らすという目標が危険にさらされます。

claude（第3投票者） 信頼度 76

まずモノリス内で境界を強化するインシデントは、他のモジュールが請求テーブルに直接触れることから発生しています。サービス分割もその境界を強制しますが、ネットワーク障害、分散トランザクション、そしてその経験のないチームへの新しい運用作業が追加されます。モノリス内でモジュールAPIとテーブル所有権を強制することで、原因をより速く修正でき、後で抽出するオプションも残ります。

決定 まずモノリス内で境界を強化する 経路 全会一致3:0 コスト $0.014

Kiratに投票させましょう：系統的レビューにおいて、単一のLLMスクリーニングパスで2人目の人間のスクリーナーを置き換えられますか？

kirat_vote が評議会に質問しました

評議会は決定しました（全会一致3:0）：LLMを追加のスクリーナーとして使用し、人間が競合を解決する。

私のものを含む3つの立場すべてが同じ方向を指しています。それぞれに理由が付いています。

舞台裏

kirat_vote ClaudeがKiratに送るもの

質問： 系統的レビューにおいて、単一のLLMスクリーニングパスで2人目の人間のスクリーナーを置き換えられますか？

記録日 2026-10-13 · KIRAT_VOTE · 労力：標準 · 1ラウンド

送信されたコンテキスト： 健康サービス研究の系統的レビューで、約3,000件のレコードのタイトルと要旨のスクリーニング。出版が計画されています。現在のプロトコル：2人の独立した人間のスクリーナー、競合は話し合いで解決。スタッフの時間は不足しています。レビューはPRISMAに従っており、ジャーナルの査読者はスクリーニングがどのように行われたかを尋ねます。関連研究を見逃すこと（誤った除外）は、無関係な研究を含めることよりも悪いです。 オプション: はい、2人目の人間によるスクリーナーを置き換える · LLMを追加のスクリーナーとして使用し、競合は人間が解決する · いいえ、2人の人間によるスクリーナーとLLMなしを維持する

評議会の結果

gpt-5.6 信頼度 94

LLMを追加のスクリーナーとして使用し、競合は人間が解決する。誤除外が主なリスクである場合、単一のLLMパスが独立した人間によるスクリーニングを置き換えるべきではありません。パフォーマンスはトピック、プロンプト、モデルバージョンによって異なる可能性があり、エラーは系統的である可能性があります。レコードの優先順位付けや不一致のフラグ付けには使用しますが、競合の解決と除外の確認は人間が行うことを要求します。PRISMA報告と再現性のために、モデル、バージョン、プロンプト、検証サンプル、決定ワークフローを文書化してください。

gemini-3.6-flash 信頼度 88

LLMを追加のスクリーナーとして使用し、競合は人間が解決する。ハイブリッドアプローチは、3,000件のタイトルと要約に対する人間の作業負荷を大幅に削減し、PRISMAや査読者が要求する方法論的厳密性を維持します。誤除外を避けなければならないため、すべての不一致を人間が解決する（または非常に感度の高いプロンプトアプローチを使用する）ことで、関連研究が見逃されないようにします。

claude（第3投票者） 信頼度 70

LLMを追加のスクリーナーとして使用し、競合は人間が解決する。誤除外はコストのかかるエラーであり、スクリーニングにおけるLLMの再現率はトピックとプロンプトによって異なります。2人目の人間を置き換えると、それらのエラーを検出するチェックがなくなり、ジャーナル査読者に説明するのが困難になります。LLMを3番目のスクリーナーとして追加し、競合を人間が解決することで、プロトコルの防御可能性を維持し、見逃しの可能性をフラグ付けできます。

決定 LLMを追加のスクリーナーとして使用し、競合は人間が解決する 経路 全会一致 3:0 コスト $0.019

2026年10月13日にkirat_voteを使用して標準の労力レベルで記録されました。各セッションは20秒未満で、コストは2セント未満でした。質問、オプション、コンテキストは送信されたとおりに正確に表示され、推論は完全に表示されます。Geminiはドイツ語で4回、ChatGPTは1回回答し、それらの回答はここで翻訳されています。無料層の質問では、Claudeは2:1で投票に負け、その異議は記録に残りました。信頼度の値は各モデル自身の自己報告です。

異なる分野からの5つのコード抜粋が、それぞれ表示されたとおりに正確に送信されます。ChatGPTとGeminiは並行してレビューし、Claudeは独自の2つの所見を追加し、すべての所見は他のモデルファミリーによってチェックされます。確認された所見のみがカウントされます。1つ選択してください。

出荷前に、Stripe支払いウェブフックのセキュリティと正確性をKiratにレビューしてもらいます。

kirat_review が評議会に質問しました

Kiratは14件の確認済み問題（4件の重大、4件の高、6件の中）を発見しました。各所見は他のモデルファミリーによってクロスチェックされました。

リストの一番上から始めてください。それぞれに推奨される修正が付属しています。

舞台裏

kirat_review ClaudeがKiratに送信するもの

記録 2026-10-13 · KIRAT_REVIEW · 労力: 標準 · 14件確認、0件却下 · $0.14

焦点: 支払いウェブフックのセキュリティと正確性

送信されたコード:

// routes/webhooks.js — payment webhook of a solo invoicing SaaS (Node 20, Express 4, Stripe, pg)
const express = require('express');
const { db } = require('../db');
const router = express.Router();

router.post('/webhooks/stripe', express.json(), async (req, res) => {
  const event = req.body;

  if (event.type === 'invoice.paid') {
    const invoice = event.data.object;
    const userId = invoice.metadata.userId;
    await db.query('UPDATE users SET plan = $1, paid_until = $2 WHERE id = $3',
      ['pro', new Date(invoice.period_end * 1000), userId]);
    await db.query('INSERT INTO payments (user_id, amount) VALUES ($1, $2)',
      [userId, invoice.amount_paid / 100]);
  }

  if (event.type === 'customer.subscription.deleted') {
    await db.query("UPDATE users SET plan = 'free' WHERE stripe_customer = '" + event.data.object.customer + "'");
  }

  res.sendStatus(200);
});

module.exports = router;

評議会の結果

  1. 重大 ウェブフックはStripe署名をチェックせずにリクエスト本文を処理します。したがって、外部の呼び出し元は偽造されたinvoice.paid\またはcustomer.subscription.deleted\イベントを送信し、ユーザーアカウントのロックを解除またはダウングレードできます。JSONパーサーはまた、Stripe署名検証に必要な未変更の生の本文を破棄します。 修正: このルートにはexpress.raw({ type: 'application/json' })\を使用し、処理前にstripe.webhooks.constructEvent(req.body, req.headers\['stripe-signature'\], webhookSecret)\を呼び出します。このルートにグローバルなJSONパーサーが既に適用されていないことを確認し、無効な署名は400で拒否します。 6行目 · gpt-5.6が発見 · gemini-3.6-flashが確認
  2. 重大 Stripeウェブフック署名の検証が欠落しています。攻撃者はこのエンドポイントに任意の偽造ウェブフックイベントを送信し、承認なしにアカウントをProに設定したり、データベースエントリを操作したりできます。 修正: stripe.webhooks.constructEvent()をStripeウェブフックシークレットとともに使用して、すべてのイベントの信頼性と整合性を検証します。 6行目 · gemini-3.6-flashが発見 · gpt-5.6が確認
  3. 重大 ユーザー入力（event.data.object.customer）をSQLクエリ文字列に直接連結するため、SQLインジェクションの脆弱性があります。 修正: 前のステートメントと同様にパラメータ化クエリを使用します: db.query('UPDATE users SET plan = $1 WHERE stripe_customer = $2', ['free', event.data.object.customer])。 18行目 · gemini-3.6-flashが発見 · gpt-5.6が確認
  4. 重大 ウェブフックはStripe署名を検証せず、express.json()はそのために必要な生の本文を破棄します。誰でも偽のinvoice.paidイベントをPOSTし、無料で任意のアカウントをproにアップグレードできます。 修正: このルートにはexpress.raw({ type: 'application/json' })を使用し、stripe.webhooks.constructEvent(req.body, req.headers['stripe-signature'], endpointSecret)でイベントを構築します。失敗した場合はリクエストを拒否します。 6行目 · claudeが発見 · gpt-5.6、gemini-3.6-flashが確認
  5. 高 顧客IDがSQLステートメントに直接挿入されます。' OR 1=1 --\のような値はWHERE句を操作し、すべてのユーザーを無料プランに設定できます。データベース構成によっては、さらなるSQLインジェクションが可能です。 修正: クエリを完全にパラメータ化します: UPDATE users SET plan = 'free' WHERE stripe\_customer = $1\と\[event.data.object.customer\]\を使用します。さらに、Stripe署名を介してイベントを認証します。 19行目 · gpt-5.6が発見 · gemini-3.6-flashが確認
  6. 高 冪等性チェックがありません。Stripeはウェブフックを少なくとも1回配信し、タイムアウトやエラー時に再試行します。同じinvoice.paid\イベントが同一の支払いエントリを複数回作成する可能性があります。 修正: StripeイベントIDまたは請求書IDを支払いレコードに保存し、UNIQUE制約で保護し、イベント処理を支払いとともに原子的に挿入/アップサートとして実行します。既に処理されたイベントには200で応答し、ビジネス操作を繰り返さないでください。 14行目 · gpt-5.6が発見 · gemini-3.6-flashが確認
  7. 高 async\ハンドラーにはエラー転送がありません。Express 4は非同期ルートハンドラーからの拒否されたプロミスを自動的にキャッチしません。DBエラーや不完全なinvoice.paid\オブジェクトは、処理されないプロミス拒否につながり、Node 20ではエラーレスポンスを制御された方法で返す代わりにプロセスを終了させる可能性があります。 修正: ハンドラーをtry/catch\でラップし、エラーをnext(err)\に渡すか、非同期ラッパーを使用します。アクセスする前に入力構造を検証し、一時的な処理エラー時には制御された方法で5xxステータスを返し、Stripeが再配信できるようにします。 6行目 · gpt-5.6が発見 · gemini-3.6-flashが確認
  8. 高 ウェブフックエンドポイントにexpress.json()を使用すると、本文が事前にJSONとして解析されます。ただし、Stripeの署名検証には未変更の生の本文が必要です。 修正: Stripeウェブフックルートハンドラーにはexpress.json()の代わりにexpress.raw({ type: 'application/json' })を使用します。 6行目 · gemini-3.6-flashが発見 · gpt-5.6が確認
  9. 中 ユーザー更新と支払いエントリは、2つの独立してコミットされたデータベース操作です。UPDATEが成功した後にINSERTが失敗した場合、対応する支払いレコードが存在しないにもかかわらず、ユーザーはProプランを取得します。 修正: 両方の操作を冪等性マーカーとともに同じクライアント上の単一のデータベーストランザクションで実行し、エラー時には完全にロールバックします。 12行目 · gpt-5.6が発見 · gemini-3.6-flashが確認
  10. 中 処理は、Stripeがイベントを生成順序と異なる順序で配信できることを考慮していません。遅延した古いinvoice.paid\はpaid\_until\をリセットでき、遅延したcustomer.subscription.deleted\はその後再アクティブ化されたユーザーをfree\に戻す可能性があります。 修正: 安定したStripe IDを使用して現在のサブスクリプション状態を調整します。たとえば、Stripeから取得し、状態遷移または最後に処理されたイベントのタイムスタンプを永続化します。少なくとも、paid\_until\を前方にのみ更新し、削除イベントを現在のユーザー状態に盲目的に適用しないでください。 12行目 · gpt-5.6が発見 · gemini-3.6-flashが確認
  11. 中 amount\_paid / 100\は、通貨に小数点以下が正確に2桁あることを確認せずに想定しています。これは、たとえばJPYでは正しくありません。さらに、通貨が一緒に保存されていないため、支払いレコードの金額には明確な単位がありません。 修正: 金額は最小通貨単位でinvoice.currency\とともに変更せずに保存することをお勧めします。主要通貨単位が必要な場合は、それぞれの通貨指数に基づいて変換を実行します。 15行目 · gpt-5.6が発見 · gemini-3.6-flashが確認
  12. 中 非同期Express 4ルートでの例外処理の欠落。データベースエラーやフィールド欠落時、これはアプリケーションをクラッシュさせる可能性のある処理されないプロミス拒否につながります。 修正: try-catchブロックを追加し、エラーをnext(err)に渡すか、express-async-handlerなどのユーティリティを使用します。 6行目 · gemini-3.6-flashが発見 · gpt-5.6が確認
  13. 中 invoice.metadata.userIdが存在することの検証がありません。メタデータまたはuserIdフィールドが欠落または未定義の場合、SQLクエリは失敗するか、無効な値で動作します。 修正: データベースクエリを実行する前に、invoice.metadataとinvoice.metadata.userIdが存在し、有効であることを明示的に確認します。 10行目 · gemini-3.6-flashが発見 · gpt-5.6が確認
  14. 中 Stripeはウェブフックを再試行し、同じイベントを複数回配信できます。配信ごとに別の支払い行が挿入されるため、収益レポートが二重カウントされます。 修正: event.id（または請求書ID）を一意の制約付きで保存し、既に処理されたイベントをスキップします。 14行目 · claudeが発見 · gpt-5.6、gemini-3.6-flashが確認

このWooCommerceインポートプラグインのセキュリティと正確性をKiratにレビューしてもらいます。

kirat_review が評議会に質問しました

Kiratは21件の確認済み問題（5件の重大、5件の高、10件の中、1件の低）を発見しました。各所見は他のモデルファミリーによってクロスチェックされました。

リストの一番上から始めてください。それぞれに推奨される修正が付属しています。

舞台裏

kirat_review ClaudeがKiratに送信するもの

記録 2026-10-13 · KIRAT_REVIEW · 労力: 標準 · 21件確認、0件却下 · $0.17

焦点: WooCommerceインポートプラグインのセキュリティと正確性

送信されたコード:

<?php
// erp-import.php — custom plugin: imports the ERP's CSV export into WooCommerce (WordPress 6, WooCommerce 9)
add_action('wp_ajax_erp_import', 'erp_import');
add_action('wp_ajax_nopriv_erp_import', 'erp_import');

function erp_import() {
    global $wpdb;
    $path = $_POST['file'];
    $rows = array_map('str_getcsv', file($path));

    foreach ($rows as $row) {
        [$sku, $name, $price, $stock] = $row;
        $id = $wpdb->get_var("SELECT post_id FROM {$wpdb->postmeta} WHERE meta_key = '_sku' AND meta_value = '$sku'");
        if (!$id) continue;
        update_post_meta($id, '_price', $price);
        update_post_meta($id, '_regular_price', $price);
        update_post_meta($id, '_stock', $stock);
        wp_update_post(['ID' => $id, 'post_title' => $name]);
    }
    echo 'Imported ' . count($rows) . ' rows';
    wp_die();
}

評議会の結果

  1. critical インポートは wp\_ajax\_nopriv\_erp\_import\ 経由で公開アクセス可能であり、認証済みフックにも権限チェックと nonce チェックがありません。その結果、匿名ユーザーや CSRF 攻撃によって商品名・価格・在庫数を変更できてしまいます。 修正方法: nopriv\ フックを削除し、処理前に manage\_woocommerce\ などの適切な権限をチェックし、リクエストを check\_ajax\_referer()\ で保護してください。 line 3 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  2. critical wp_ajax_nopriv_erp_import フックにより、未認証の訪問者がインポート機能にアクセスできます。 修正方法: nopriv フックを削除し、current_user_can('manage_options') を使用して権限をチェックしてください。 line 4 · found by gemini-3.6-flash · confirmed by gpt-5.6
  3. critical $_POST['file'] のファイルパスがチェックなしで file() に渡されており、パストラバーサルや任意ファイル読み取り（LFI）が可能になります。 修正方法: $_FILES 経由でファイルアップロードを処理するか、許可されたディレクトリ（例: wp_upload_dir()）に対して入力パスを厳密に検証してください。 line 7 · found by gemini-3.6-flash · confirmed by gpt-5.6
  4. critical $sku がサニタイズなしで SQL クエリに直接挿入されるため、SQL インジェクションの脆弱性があります。 修正方法: $wpdb->prepare() を使用してプリペアドステートメントを利用してください。 line 11 · found by gemini-3.6-flash · confirmed by gpt-5.6
  5. critical インポートは wp_ajax_nopriv に登録されており、権限チェックも nonce もありません。任意の訪問者がこれを実行し、価格・在庫・商品名を上書きできます。 修正方法: nopriv フックを削除し、current_user_can('manage_woocommerce') をチェックし、何かを行う前に check_ajax_referer() で nonce を検証してください。 line 4 · found by claude · confirmed by gpt-5.6, gemini-3.6-flash
  6. high クライアントから提供されたパスがチェックなしで file()\ に渡されます。これにより、読み取り可能なローカルファイルや、allow\_url\_fopen\ によっては外部・内部 URL も処理され、不要なファイルアクセスやブラインド SSRF が可能になります。 修正方法: 自由に選択されたパスを受け入れないでください。サーバー側で既知のアップロード ID のみを使用し、正規化されたパスを固定のインポートディレクトリと照合し、通常のローカル CSV ファイルのみを許可してください。 line 8 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  7. high $sku\ は CSV から取得され、SQL に直接挿入されます。SQL メタ文字を含む SKU 値はクエリを操作でき、特に任意の投稿 ID を更新対象として選択できます。 修正方法: $wpdb-\>prepare()\ を使用してクエリをパラメータ化するか（例: meta\_value = %s\）、SKU による商品検索の WooCommerce 関数を使用してください。 line 13 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  8. high file()\ は入力全体をメモリに読み込み、array\_map()\ はさらに完全なパース済み配列を作成します。サイズ制限がないため、大規模または無限のリモートリソースがメモリ・実行時間・PHP ワーカーを枯渇させる可能性があり、公開アクセス可能性がこれを悪化させます。 修正方法: ファイルサイズと行数を制限し、fopen()\ でファイルをローカルに開き、fgetcsv()\ でレコードをストリーミング処理してください。さらに、レート制限または管理されたバックグラウンドジョブを使用してください。 line 9 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  9. high CSRF 保護（nonce 検証）がありません。 修正方法: 関数の先頭で check_ajax_referer() を呼び出してください。 line 6 · found by gemini-3.6-flash · confirmed by gpt-5.6
  10. high ファイルパスがリクエストから直接取得され、file() に渡されます。攻撃者は Web サーバーが読み取れる任意のファイル、または allow_url_fopen が有効な場合はリモート URL を読み取ることができます。 修正方法: wp_handle_upload() を通じてアップロードされたファイルを受け入れるか、固定のインポートディレクトリからのみ読み取ってください。リクエストからパスを取得しないでください。 line 8 · found by claude · confirmed by gpt-5.6, gemini-3.6-flash
  11. medium すべての行に正確に 4 つの使用可能な列があると想定されています。空行や破損した行は欠落値を生成し、警告を発生させ、名前・価格・在庫が意図せず空の値に設定される可能性があります。 修正方法: 分割前に列数と必須フィールドをチェックし、空行をスキップし、明確なエラーメッセージで不正なレコードを拒否してください。 line 12 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  12. medium file()\ と str\_getcsv()\ の組み合わせは、各物理行を個別にパースします。埋め込まれた改行を含む有効な CSV フィールドは、複数の不正なレコードに分割されます。 修正方法: fgetcsv()\ で CSV をストリームとして読み取ってください。この関数はレコード境界をまたいで複数行の正しく引用されたフィールドを処理します。 line 9 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  13. medium 価格と在庫はチェックなしで任意の文字列として保存されます。数値以外の値、誤った小数形式、または許容されない在庫レベルは商品データを破損させ、一貫性のない計算につながる可能性があります。 修正方法: 書き込み前に価格と在庫を検証し、wc\_format\_decimal()\ や wc\_stock\_amount()\ などの WooCommerce ヘルパーで正規化してください。ビジネス上無効または許容されない値は拒否してください。 line 15 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  14. medium WooCommerce データは投稿メタとして直接変更されます。その結果、\_stock\_status\ などの関連状態、商品ルックアップテーブル、場合によってはキャッシュが新しい価格と在庫レベルと確実に同期されません。 修正方法: wc\_get\_product()\ で商品を読み込み、set\_regular\_price()\、set\_price()\、set\_stock\_quantity()\ などの CRUD メソッドを使用し、ビジネスルールに従って在庫ステータスまたは manage\_stock\ を設定し、その後 save()\ を呼び出してください。 line 15 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  15. medium SKU ルックアップはすべての投稿メタを考慮し、投稿タイプも、見つかった ID が実際に WooCommerce 商品またはバリエーションであるかもチェックしません。重複または無関係な \_sku\ メタがある場合、非決定的な一致も更新されます。 修正方法: wc\_get\_product\_id\_by\_sku()\ を使用し、結果を wc\_get\_product()\ と期待される商品タイプで検証してください。重複 SKU はインポートエラーとして扱ってください。 line 13 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  16. medium update\_post\_meta()\ と wp\_update\_post()\ の戻り値が無視されています。インポートは部分的に失敗または中断される可能性がありますが、読み取られた行の総数が正常にインポートされたとして報告されます。 修正方法: 商品ごとに成功と失敗を記録し、wp\_update\_post(..., true)\ を使用し、実際に更新されたレコードのみをカウントし、構造化されたエラーレスポンスを返してください。大規模なインポートには再開可能なバックグラウンドジョブを提供してください。 line 15 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  17. medium CSV の各行に対して、少なくとも 1 つのルックアップクエリと複数の個別の書き込み操作が同期的に実行されます。そのため、大規模なインポートは多数のデータベースラウンドトリップを引き起こし、リクエストタイムアウトに陥り、部分的にしか更新されないカタログを残す可能性があります。 修正方法: インポートを制限されたバッチでバックグラウンドプロセスとして実行し、SKU を一括で解決し、進行状況と再開状態を保存してください。 line 11 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  18. medium file() はファイル全体を一度にメモリに読み込むため、大きな CSV ファイルではメモリ枯渇エラーが発生します。 修正方法: fopen() と fgetcsv() を使用してファイルを 1 行ずつストリーミングしてください。 line 8 · found by gemini-3.6-flash · confirmed by gpt-5.6
  19. medium 配列の分割は、各行に少なくとも 4 つの要素が含まれることを前提としています。そうでない場合、PHP 警告または未初期化インデックスエラーが発生します。 修正方法: 展開する前に、count($row) で十分な列が存在するかチェックしてください。 line 10 · found by gemini-3.6-flash · confirmed by gpt-5.6
  20. medium データベースクエリと投稿更新はループ内で個別に実行され（N+1 問題）、実行時間が大幅に遅くなります。 修正方法: インポートをバッチに分割し、クエリ/更新をまとめてください。 line 11 · found by gemini-3.6-flash · confirmed by gpt-5.6
  21. low file()\ からのエラーがチェックされていません。パスが存在しない、読み取れない、またはサポートされていない場合、file()\ は false\ を返し、その後 array\_map()\ は現在の PHP バージョンで TypeError\ をスローする可能性があります。 修正方法: オープンと読み取りを明示的にチェックし、PHP 警告を制御フローとして使用せず、エラー時に適切な HTTP または wp\_send\_json\_error()\ レスポンスを返してください。 line 9 · found by gpt-5.6 · confirmed by gemini-3.6-flash

パン屋の注文ページの注文・支払いフローをセキュリティと正確性の観点から Kirat にレビューさせてください。

kirat_review が評議会に依頼

Kirat は 14 件の確認済み問題（重大 4 件、高 4 件、中 5 件、低 1 件）を発見しました。各発見は他のモデルファミリーによって相互検証されました。

リストの先頭から順に確認してください。各項目には推奨される修正方法が付属しています。

舞台裏

kirat_review Claude が Kirat に送信する内容

記録日 2026-10-13 · KIRAT_REVIEW · 労力: 標準 · 14 件確認、0 件却下 · $0.11

焦点: 注文・支払いフローのセキュリティと正確性

送信されたコード:

// routes/order.js — order endpoint of the bakery's ordering page (Node 20, Express 4, pg)
const express = require('express');
const { pool } = require('../db');
const { sendConfirmation } = require('../mail');
const router = express.Router();

router.post('/order', async (req, res) => {
  const { cakeId, pickupDate, name, email, price, note } = req.body;

  const cake = await pool.query(\`SELECT * FROM cakes WHERE id = ${cakeId}\`);
  if (!cake.rows.length) return res.status(404).send('Unknown cake');

  const order = await pool.query(
    'INSERT INTO orders (cake_id, pickup_date, name, email, amount, note) VALUES ($1, $2, $3, $4, $5, $6) RETURNING id',
    [cakeId, pickupDate, name, email, price, note]
  );

  sendConfirmation(email, order.rows[0].id);
  res.redirect(\`/pay?order=${order.rows[0].id}&amount=${price}\`);
});

module.exports = router;

評議会からの結果

  1. critical cakeIdはSQL文字列に直接補間されます。攻撃者はSQL式や追加のステートメントを注入し、データの読み取りや変更、データベースへの負荷をかけることができます。 修正: このクエリもパラメータ化してください。例: SELECT... FROM cakes WHERE id = $1\ を \[cakeId\]\ とともに使用し、さらにcakeIdが期待される型であることを確認してください。 line 10 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  2. critical SQLクエリ内でのcakeIdの直接的なテンプレート文字列補間によるSQLインジェクションの脆弱性。 修正: パラメータ化されたSQLクエリを使用してください: pool.query('SELECT * FROM cakes WHERE id = $1', [cakeId])。 line 9 · found by gemini-3.6-flash · confirmed by gpt-5.6
  3. critical クライアント側での価格操作が可能です。価格はreq.bodyから取得され、そのまま保存・処理されます。 修正: 価格はサーバー側でデータベースから読み取り（cake.rows[0].price）、クライアントから送信された値を信頼しないでください。 line 8 · found by gemini-3.6-flash · confirmed by gpt-5.6
  4. critical リクエストボディのcakeIdがSQL文字列に補間されています: SQLインジェクション。 修正: パラメータ化されたクエリを使用してください: SELECT * FROM cakes WHERE id = $1。 line 10 · found by claude · confirmed by gpt-5.6, gemini-3.6-flash
  5. high 保存され、支払いフローに渡される金額は完全に req.body.price\ から来ています。顧客は任意のケーキに対して、操作された、負の、または非常に小さな金額を入力できます。 修正: 価格は選択されたケーキまたは不変の価格バージョンからサーバー側でのみ決定してください。この金額で支払いプロバイダーにサーバー側の支払いセッションを作成し、支払い確認時に期待される金額をサーバー側で再度検証してください。 line 16 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  6. high 注文は、正常な支払いが検証される前に作成され、確認が送信されます。中断された、または意図的に支払われていない取引は、確認済みの注文として表示され、自由に生成される可能性があります。 修正: 注文は最初に pending\_payment\ などのステータスで作成してください。認証され、冪等に処理された支払いプロバイダー通知の後にのみ paid\ に切り替え、その後確認を送信するか、生産または予約をトリガーしてください。 line 19 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  7. high 非同期のExpress 4ルートでのエラーハンドリングの欠如。データベースまたはランタイムエラーは、未処理のプロミス拒否につながります。 修正: try/catchブロックを使用し、next(err)でエラーを転送するか、express-async-errorsなどのパッケージを使用してください。 line 8 · found by gemini-3.6-flash · confirmed by gpt-5.6
  8. high 金額はクライアントから取得されるため（リクエストボディの価格）、顧客は自分の価格を設定できます。 修正: サーバー上のcakes行から価格を読み取り、クライアントの値を無視してください。 line 15 · found by claude · confirmed by gpt-5.6, gemini-3.6-flash
  9. medium 非同期ハンドラーにはエラー転送がありません。Express 4は async\ ハンドラーからの拒否されたプロミスを自動的に処理しないため、データベースまたは同期メールエラーが未回答のリクエストや未処理の拒否につながる可能性があります。 修正: ハンドラーを try/catch\ でラップし、エラーを next(err)\ に渡すか、確立された非同期ラッパーを使用してください。さらに、中央エラーハンドリングを構成してください。 line 7 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  10. medium sendConfirmation\ の結果は待機もエラー処理もされていません。プロミス拒否が未処理のままになる可能性があります。同時に、メールの送信が失敗した可能性があるにもかかわらず、クライアントはすでに成功応答を受け取ります。 修正: 確認済みの支払い後に、永続的なアウトボックスまたはリトライ付きのジョブキューを介して送信を実行してください。少なくとも、プロミスを待機し、エラーを制御された方法でログに記録または処理してください。 line 19 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  11. medium 冪等性保護がありません。ブラウザの再試行、ダブルクリック、またはネットワークの再試行により、新しい注文が作成され、複数の確認または支払い試行が発生する可能性があります。 修正: 冪等性キーまたはチェックアウトセッションIDを受け入れ、一意の制約で保護し、再試行時に既存の注文を返してください。 line 13 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  12. medium pickupDate、name、email、price、noteは、ビジネスまたは構文の検証なしに処理されます。これは、例えば、過去または無効な受け取り日、顧客データの欠落、不適切なフィールド値が保存される可能性があることを意味します。データベースエラーも遅れて、制御されない方法でのみ発生します。 修正: 型、必須フィールド、長さ制限、正規化された形式を持つリクエストスキーマを使用してください。受け取り日をタイムゾーン、リードタイム、許容される営業時間または容量ルールに対して確認してください。価格をクライアント入力として受け入れないでください。 line 8 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  13. medium sendConfirmationへの非同期呼び出しは、待機もエラーキャッチもされていません。 修正: sendConfirmationの前にawaitを置き、メール送信時に発生する可能性のあるエラーを処理してください。 line 17 · found by gemini-3.6-flash · confirmed by gpt-5.6
  14. low email、pickupDate、name、noteなどのフィールドの入力検証が不完全です。 修正: リクエストデータを処理する前に、スキーマ検証（例: Zodまたはexpress-validatorを使用）を実装してください。 line 8 · found by gemini-3.6-flash · confirmed by gpt-5.6

Kiratにこの請求機能の正確性とデータ整合性をチェックしてもらいます。

kirat_review が評議会に依頼

Kiratは16件の確認済みの問題（1件のcritical、11件のhigh、3件のmedium、1件のlow）を発見しました。各発見は他のモデルファミリーによって相互チェックされました。

リストの一番上から始めてください。各項目には推奨される修正が付属しています。

舞台裏

kirat_review ClaudeがKiratに送信するもの

RECORDED 2026-10-13 · KIRAT_REVIEW · EFFORT: STANDARD · 16 CONFIRMED, 0 REJECTED · $0.14

焦点: 請求機能の正確性とデータ整合性

送信されたコード:

// billing/applyCredit.ts — billing module in the monolith (TypeScript, node-postgres)
import { pool } from '../db';

export async function applyCredit(customerId: string, invoiceId: string, creditCents: number) {
  const inv = await pool.query('SELECT total_cents, status FROM invoices WHERE id = $1', [invoiceId]);
  const balance = await pool.query('SELECT credit_cents FROM customers WHERE id = $1', [customerId]);

  const available = balance.rows[0].credit_cents;
  if (creditCents > available) throw new Error('Not enough credit');

  const newTotal = inv.rows[0].total_cents - creditCents;
  await pool.query('UPDATE invoices SET total_cents = $1 WHERE id = $2', [newTotal, invoiceId]);
  await pool.query('UPDATE customers SET credit_cents = credit_cents - $1 WHERE id = $2', [creditCents, customerId]);

  if (newTotal <= 0) {
    await pool.query("UPDATE invoices SET status = 'paid' WHERE id = $1", [invoiceId]);
  }
  return newTotal * 1.19 / 100;
}

評議会からの結果

  1. critical データベーストランザクションと行ロックが欠落しています。並列リクエストがあると、競合状態（例：クレジットの二重使用）や、エラー発生時の不完全な更新が発生する可能性があります。 修正: プールからBEGIN/COMMIT付きのクライアントを使用し、SELECT FOR UPDATEを使用して行をロックし、アトミックに更新してください。 line 5 · found by gemini-3.6-flash · confirmed by gpt-5.6
  2. high 3つの関連する更新がデータベーストランザクション内で実行されていません。顧客クレジットの引き落としやステータス変更が失敗した場合、クレジットが正しく請求されたりステータスが設定されたりすることなく、請求書がすでに減額されている可能性があります。 修正: プールから専用クライアントを取得し、BEGINとCOMMITの間で全てのチェックと更新を実行します。エラー時にはROLLBACKを使用してください。 line 11 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  3. high 請求書が最初に読み取られ、後で絶対的な計算値で上書きされます。2つの並列呼び出しが同じ開始値を読み取り、互いに上書きする可能性があります。両方のクレジット引き落としは行われますが、請求書には1つのクレジットのみが完全に表示されたままになります。 修正: 同じトランザクション内で影響を受ける請求書をSELECT... FOR UPDATEでロックするか、適切な条件でUPDATE... SET total_cents = total_cents - $1を使用して金額をアトミックに変更してください。 line 4 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  4. high 顧客クレジットのチェックと引き落としがアトミックではありません。並列呼び出しが同じ利用可能な残高を確認し、その後クレジットをゼロ以下に減らす可能性があります。 修正: 顧客レコードをトランザクションでロックするか、条件付きUPDATE（例：UPDATE customers SET credit_cents = credit_cents - $1 WHERE id = $2 AND credit_cents >= $1 RETURNING credit_cents）を使用し、返された行が正確に1つであることを要求してください。 line 8 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  5. high 請求書が指定された顧客に属しているかどうかがチェックされていません。その結果、顧客のクレジットがinvoiceIdを介して識別された任意の請求書に適用される可能性があります。 修正: 所有関係を介して請求書と顧客を照会および更新してください。例：WHERE invoices.id = $1 AND invoices.customer_id = $2。一致しない場合は中止してください。 line 4 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  6. high 適用されるクレジットが未払い請求額に上限設定されていません。creditCentsがtotal_centsより大きい場合、負の請求額が保存され、過剰な顧客クレジットが消費されます。 修正: 未払い請求額までの金額のみを許可するか、実際に使用された金額をmin(creditCents, total_cents)として決定し、この金額のみを顧客クレジットから引き落としてください。 line 10 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  7. high 負の値、非整数値、または安全に表現できない値が拒否されていません。特に、負のcreditCents値は請求額を増加させ、同時に負の値の減算を通じて顧客クレジットも増加させます。 修正: データベースアクセスの前にNumber.isSafeInteger(creditCents) && creditCents > 0を要求してください。金額は一貫して整数のセント値として扱ってください。 line 8 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  8. high 読み取られた請求書ステータスが完全に無視されています。したがって、クレジットはすでに支払済み、キャンセル済み、またはその他の理由で変更不可能な請求書にも適用される可能性があります。その結果、支払済みの請求書が負になる可能性があります。 修正: 許可される開始ステータスを明示的に定義し、UPDATE条件でアトミックにチェックしてください。例：AND status = 'open'。一致しない場合は操作を中止してください。 line 4 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  9. high 事前チェックなしでbalance.rows[0]とinv.rows[0]にアクセスしています。顧客または請求書が見つからない場合、アプリケーションは未処理のTypeErrorでクラッシュします。 修正: アクセス前にinv.rows.lengthとbalance.rows.lengthをチェックし、明示的なエラーメッセージをスローしてください。 line 8 · found by gemini-3.6-flash · confirmed by gpt-5.6
  10. high creditCentsの負の値に対する検証が欠落しています。負の値はチェック（creditCents > available）をバイパスし、誤ったクレジットまたは請求書の調整につながります。 修正: creditCentsが0より大きい正の整数であることを確認してください。 line 9 · found by gemini-3.6-flash · confirmed by gpt-5.6
  11. high 読み取りと3つの更新がトランザクション外かつ行ロックなしで実行されています。2つの並行呼び出しが両方ともクレジットチェックを通過し、同じクレジットを2回使用する可能性があり、更新間のクラッシュにより請求書とクレジット残高が不整合のままになります。 修正: 単一のクライアントで全てを1つのトランザクションで実行し、SELECT... FOR UPDATEで行をロックし、すべての更新が成功した後にのみコミットしてください。 line 5 · found by claude · confirmed by gpt-5.6, gemini-3.6-flash
  12. high この関数は、請求書が顧客に属しているか、まだオープンであるかを決してチェックしません。ある顧客のクレジットが別の顧客の請求書、またはすでに支払済みの請求書に適用される可能性があります。 修正: WHERE id = $1 AND customer_id = $2 AND status = 'open'で請求書を選択し、行が返されない場合は失敗させてください。 line 11 · found by claude · confirmed by gpt-5.6, gemini-3.6-flash
  13. medium 請求書と顧客の存在がチェックされていません。不明なIDの場合、rows[0]へのアクセスは制御されたビジネスエラーの代わりにランタイムエラーにつながります。さらに、これが明らかになる前に両方のクエリが不必要に実行されます。 修正: 両方のクエリでrowCountまたはrows.lengthをチェックし、定義されたnot-foundエラーを発生させてください。チェックをトランザクションに統合し、可能であればリレーショナルクエリに統合してください。 line 4 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  14. medium 戻り値は、保存されたセント額とも、主要通貨への単純な変換とも一致しません。一律19パーセントを加算し、浮動小数点演算を使用しています。その結果、呼び出し元は、実際に保存されている残りの請求残高と、税および丸めの点で異なる値を受け取る可能性があります。 修正: 残り金額をセントでそのまま返すか、明確に型指定された戻り値を定義してください。ビジネス上の理由で税計算が必要な場合は、税率と丸めルールを請求書データから取得し、整数または10進演算で計算してください。 line 17 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  15. medium 財務計算にIEEE 754浮動小数点演算（newTotal * 1.19 / 100）を使用しています。これは精度と丸め誤差につながります。 修正: 整数（BigInt/Math.round）でセント単位で一貫して計算するか、正確な10進演算用のライブラリを使用してください。 line 18 · found by gemini-3.6-flash · confirmed by gpt-5.6
  16. low 請求書ステータスの個別のUPDATEコマンドにより、不要なデータベースラウンドトリップが発生します。 修正: total_centsとstatusの更新を単一のUPDATEクエリに結合してください。 line 12 · found by gemini-3.6-flash · confirmed by gpt-5.6

Kiratに、系統的レビューのためのスクリーニング分析スクリプトの正確性をチェックしてもらってください。

kirat_review が評議会に依頼しました

Kiratは11件の確認済み問題（6件×高、4件×中、1件×低）を発見しました。各発見は他のモデルファミリーによって相互チェックされました。

リストの一番上にあるものから始めてください。それぞれに推奨される修正が付属しています。

舞台裏

kirat_review ClaudeがKiratに送信するもの

記録日 2026-10-13 · KIRAT_REVIEW · 労力: 標準 · 11件確認、0件却下 · $0.09

焦点: 系統的レビューのためのスクリーニング分析の正確性

送信されたコード:

# screening/agreement.py — compares two screeners' include/exclude decisions (Python 3.12, pandas)
import pandas as pd

a = pd.read_csv('screener_a.csv')   # columns: record_id, decision ('include'/'exclude')
b = pd.read_csv('screener_b.csv')

merged = a.merge(b, on='record_id', suffixes=('_a', '_b'))

agree = (merged.decision_a == merged.decision_b).mean()
p_inc_a = (merged.decision_a == 'include').mean()
p_inc_b = (merged.decision_b == 'include').mean()
expected = p_inc_a * p_inc_b + (1 - p_inc_a) * (1 - p_inc_b)
kappa = (agree - expected) / (1 - expected)

conflicts = merged[merged.decision_a != merged.decision_b]
excluded = merged[merged.decision_a == 'exclude']

print(f'Records screened: {len(a)}')
print(f"Cohen's kappa: {kappa:.2f}")
excluded.record_id.to_csv('excluded.csv', index=False)
conflicts.to_csv('conflicts.csv', index=False)

評議会からの結果

  1. high デフォルトの内部結合では、2つのファイルのいずれか一方にしか存在しないrecord_id値がすべて削除されます。そのため、カッパ係数とコンフリクトは共通部分に対してのみ計算され、欠落したスクリーニング結果は可視化されません。同時に、18行目の「Records screened」は、実際に分析された共通部分ではなく、aの長さを報告します。 修正: マージインジケータ付きの外部結合を使用し、IDセットを明示的に比較し、欠落した判定を個別に報告するか、データエラーとして扱います。各メトリクスについて、実際に使用した分母を出力します。 line 7 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  2. high record_idの一意性がチェックされていません。重複したIDはマージ中に多対多のデカルト積を引き起こし、個々の研究を複数回重み付けするため、一致率、有病率、カッパ係数、出力ファイルが歪められます。 修正: マージの前に、両方のファイルでrecord_idが非NULLかつ一意であることを確認し、重複がある場合は中止します。さらに、merge(..., validate='one_to_one')を使用します。 line 7 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  3. high 判定値が検証されていません。欠損値、タイプミス、大文字/小文字、追加のカテゴリは、包含有病率の計算時に暗黙的に「除外」として扱われますが、観測された一致率は正確な値を比較します。そのため、計算は二値のコーエンのカッパ係数に対応しなくなり、矛盾した結果を生む可能性があります。 修正: 分析前にdecisionを制御された方法で正規化し、すべての値が正確に'include'または'exclude'であることを確認します。欠落または不明な値は、データエラーまたは不完全なスクリーニングとして個別に処理します。 line 9 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  4. high excludedには、スクリーナーAによって除外されたすべてのレコードが含まれ、スクリーナーBが「include」と判定したコンフリクトも含まれます。そのため、そのようなレコードはexcluded.csvとconflicts.csvの両方に書き込まれます。excluded.csvが最終的に除外されたヒットを表すことを意図している場合、未解決のコンフリクトがレビューから誤って削除される可能性があります。 修正: 文書化された優先順位ルールがない場合、一致する除外のみを選択します。つまり、(decision_a == 'exclude') & (decision_b == 'exclude')です。コンセンサス判定が行われるまで、コンフリクトはconflicts.csvにのみ保持します。 line 16 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  5. high 除外された研究のフィルタリングが正しくありません: 'excluded'はスクリーナーAの判定のみを考慮します（'merged.decision_a == "exclude"'）。コンフリクトがある場合（スクリーナーAが除外、スクリーナーBが包含）、その研究は誤って除外としてカウントされます。 修正: 両方のスクリーナーが一貫して'exclude'を選択した場合のみ除外をエクスポートします（例: '(merged.decision_a == "exclude") & (merged.decision_b == "exclude")'）、またはコンフリクトが解決されるまで待ちます。 line 16 · found by gemini-3.6-flash · confirmed by gpt-5.6
  6. high excluded.csvには、スクリーナーAが除外したすべてのレコードが含まれ、スクリーナーBが含めたコンフリクトも含まれます。これらのレコードはコンフリクト議論の前にドロップされ、これはプロトコルが回避しなければならないまさに誤った除外です。 修正: 両方のスクリーナーが除外したレコードのみを除外します: merged[(merged.decision_a == 'exclude') & (merged.decision_b == 'exclude')]; すべてのコンフリクトを最初に解決に送ります。 line 16 · found by claude · confirmed by gpt-5.6, gemini-3.6-flash
  7. medium 両方のスクリーナーが同じカテゴリのみを使用する場合、expectedは1に等しく、カッパ係数の分母は0になります。結果はNaNになるか、ゼロ除算の警告を生成する可能性があります。フォーマットされた出力「nan」は、カッパ係数が数学的に未定義であることを説明しません。空の分析共通部分も、意味のないNaNメトリクスにつながります。 修正: 除算の前に、ペアになった有効な判定が存在するかどうか、および1 - expectedが0より大きいかどうかを確認します。縮退したケースでは、カッパ係数を「未定義」と明示的に報告し、基礎となる頻度を報告します。 line 13 · found by gpt-5.6 · confirmed by gemini-3.6-flash
  8. medium 期待される偶然の値'expected'が1に等しい場合（例: 両方のスクリーナーが100%のレコードで同じカテゴリを選択した場合）、コーエンのカッパ係数でゼロ除算が発生する可能性があります。 修正: 計算の前に、'1 - expected == 0'かどうかをキャッチし、その場合に定義された値（例: 1.0またはNaN）を割り当てます。 line 12 · found by gemini-3.6-flash · confirmed by gpt-5.6
  9. medium デフォルトの内部結合によるレコードのサイレントな破棄。スクリーナーAとスクリーナーBが異なる'record_id'のセットを評価した場合、処理された研究の不一致は報告されません。さらに、コンソール出力の'len(a)'は、実際にマッチした研究の数に対応しません。 修正: 'len(a) == len(b) == len(merged)'が成立するかどうかを確認するか、外部結合を実行して不完全に評価されたレコードを明示的に表示します。 line 7 · found by gemini-3.6-flash · confirmed by gpt-5.6
  10. medium 内部マージは、一方のスクリーナーのみが判定したレコードをサイレントにドロップし、印刷されたカウントはlen(a)を使用します。スクリーニングされていないレコードは、一致率とPRISMA番号の両方から消えます。 修正: how='outer', indicator=Trueでマージし、いずれかのスクリーナーからの判定がないレコードがある場合は失敗または報告します。 line 7 · found by claude · confirmed by gpt-5.6, gemini-3.6-flash
  11. low 入力サニタイズと'decision'列の欠損値の処理が欠落しています。大文字/小文字、空白、またはNaN値は、誤った比較につながります。 修正: 比較の前に列の値をクリーンアップし（例: '.str.strip().str.lower()'）、データ型の安全性を確保します。 line 9 · found by gemini-3.6-flash · confirmed by gpt-5.6

表示: メンバーが書いたすべての確認済みの所見とその修正。検証者の推論は彼らの判定に短縮されています。重複はマージされていないため、複数のメンバーが報告すると、同じ問題が複数回表示されることがあります。コード、フォーカス、およびClaude自身の所見は英語で送信されました。メンバーがドイツ語で書いた所見はここで翻訳されています。

さまざまな分野からの5つのアイデアブリーフ。ChatGPTとGeminiは3つのトラックで作業し、Claudeは1つのアイデアを追加し、両方のメンバーがすべてのアイデアを匿名で評価します（それぞれ1〜10、最大20ポイント）。1つを選択してください。

私の2つのブログ投稿はGoogleで上位にランクされていますが、トライアルを開始する読者はほとんどいません。Kiratとアイデアをブレインストーミングしてください。

kirat_brainstorm asked the council

評議会は14のアイデアを考案し、それぞれを匿名で評価しました。トップ3:

  1. 14日間の時計を3回の実際の送信に置き換える (18/20ポイント)
  2. 記事内でタスクを完了する (17/20ポイント)
  3. 追跡記事をリカバリーコンソールに変える (17/20ポイント)

舞台裏

kirat_brainstorm What Claude sends to Kirat

RECORDED 2026-10-13 · KIRAT_BRAINSTORM · EFFORT: STANDARD · 14 IDEAS · 1 ROUND · $0.11

トピック: 2つのGoogleランキングブログ投稿の読者を、フリーランサー向け請求ツールのトライアル登録に変えるための、ソロ開発者向けのアイデア

送信されたコンテキスト: フリーランサー向け請求ツール、月額USD 19、14日間の無料トライアル、5か月後に30人の有料顧客。登録は主にGoogleでランク付けされた2つのブログ投稿（フリーランスの請求書の書き方、支払い遅延の追跡方法）から来ています。トライアルの約12%がコンバージョンします。開発者には本業があり、製品に週約10時間を費やしています。ハード: 有料広告なし。ハード: これに週最大3時間。

評議会の結果

  1. 1 14日間の時計を、実際の送信3回に置き換える gpt-5.6 · rule breaker · 18/20点 (9 + 9) 14暦日ではなく、請求書または支払い督促を3回送信した後に終了するトライアルをテストする。これは、期間限定トライアルが適切であるという暗黙の前提を意図的に破るものである。フリーランサーは任意の2週間の間に請求書を発行するとは限らないため、現在のトライアルは製品がその価値を証明する前に期限切れになる可能性がある。月額19ドルのプランは変更せず、コホートごとのアクティベーションから有料化へのコンバージョンを比較する。
  2. 2 記事内でタスクを完了させる gpt-5.6 · within brief · 17/20点 (9 + 8) 「フリーランス請求書の書き方」に小さな請求書ビルダーを埋め込む。読者はクライアント、金額、支払期日、支払条件を入力し、完成したプレビューを見る。「この請求書を送信または保存」は、その詳細がすでに読み込まれたトライアルを作成し、学習と実行の間のギャップをなくす。これを週3時間を上限に毎週スライスして構築し、その後はメンテナンスをほぼゼロに保つ。
  3. 3 督促記事を回収コンソールに変える gpt-5.6 · neighbor · 17/20点 (9 + 8) 埋め込み請求書ビルダーのワンステップ置き換えとして、読者が延滞額と支払期日を入力して、日付入りの3メッセージ督促シーケンスを生成できるようにする。トライアルを開始すると、債務者が保存され、メッセージがスケジュールされ、送信準備ができた最初の下書きが開く。これは、サインアップ前の有用な出力という最も強力なパターンを維持しながら、2番目の投稿の意図に一致する。
  4. 4 コンバージョンの瞬間を債務者のカレンダーに載せる gpt-5.6 · within brief · 16/20点 (7 + 9) 延滞支払いに関する記事で、支払期日と、1日目、7日目、14日目にエスカレーションするフォローアップのリマインダーを含む生成された.icsファイルを提供する。各カレンダーイベントには、関連する督促ワークフローを日付が事前入力された状態で開くディープリンクが含まれており、読者が単に調査しているときではなく、問題が現実のものとなったときに戻ってくるようにする。メールキャプチャは不要で、無人で実行できる。
  5. 5 トライアル期間の代わりに、1クライアント向けの永久無料プラン gemini-3.6-flash · rule breaker · 16/20点 (8 + 8) このアイデアは、14日間のトライアルというソフトな制約を破り、それを正確に1人のアクティブなクライアントのためのフリーミアムプランに置き換える。フリーランサーは、最初のクライアントに対しては永久に無料で製品を使用でき、2人目のクライアントが追加されるとすぐに19ドルの定額料金にシームレスにアップグレードできる。
  6. 6 差し迫った問題によって読者を振り分ける gpt-5.6 · within brief · 14/20点 (8 + 6) 一般的なトライアルバナーを、「最初の請求書が必要」「定期的に請求書を発行する」「クライアントがすでに支払いを遅延している」などの3つのインライン選択肢に置き換える。各選択肢は、同じホームページではなく、一致するオンボーディング状態を開き、記事のセクションIDは賢明なデフォルトを事前選択できる。CTAクリックだけでなく、完了したトライアルアクティベーションを測定し、週に1つのルートをテストする。
  7. 7 3つのフォレンジック請求書メイクオーバーを公開する gpt-5.6 · within brief · 14/20点 (8 + 6) 許可を得て、3つの匿名化された顧客請求書を、何が変わったのか、なぜ変わったのかを正確に示す静的なビフォーアフターのケーススタディに変える。各メイクオーバーをランキング投稿の関連するアドバイスの隣に挿入し、同じ修正された構造を編集可能なトライアルテンプレートとして開くCTAを付ける。小規模な顧客ベースからの具体的な証拠は、広範な推薦文よりも信頼性が高い場合がある。
  8. 8 読者が両方の投稿間で進捗を持ち運べるようにする gpt-5.6 · within brief · 14/20点 (7 + 7) 読者が選択した通貨、請求書ステージ、支払期日をブラウザにローカルに保存し、2つの記事間を移動するときにその状態を使用する。請求書プランを作成した人は、後で「あなたの請求書は現在3日遅延しています—準備されたフォローアップを開いてください」などのコンテキストプロンプトを、トライアルオンボーディングが事前入力された状態で表示できる。これにより、アカウントや継続的なコンテンツ制作を必要とせずに、軽量な2投稿ジャーニーが作成される。
  9. 9 インタラクティブなリマインダーレター設定ツール gemini-3.6-flash · within brief · 14/20点 (7 + 7) 延滞支払いのフォローアップに関する記事に、エスカレーションする支払いリマインダーレターのジェネレーターを追加する。テキストが入力された後、テンプレートが生成され、トライアルアカウントで将来の請求書の自動支払いリマインダーを設定するCTAと組み合わされる。
  10. 10 事前登録なしの即時送信マジックリンク gemini-3.6-flash · neighbor · 14/20点 (8 + 6) コンテンツ内ジェネレーターの変異：読者はブログ記事に直接請求書の詳細を入力し、「今すぐ請求書を送信」をクリックする。バックグラウンドで、システムはシームレスにトライアルアカウントを作成し、メールを直接送信する。パスワードはその後設定されるだけである。
  11. 11 ブログ記事内のライブ請求書ジェネレーター gemini-3.6-flash · within brief · 13/20点 (6 + 7) 請求書の書き方に関する記事に、シンプルでインタラクティブなフォームツールを直接埋め込む。読者は請求書の詳細を入力し、完成したPDFを即座に無料でダウンロードできる。目立つボタンは、ワンクリックで請求書をデジタル送信し、14日間のトライアルアカウントで支払い状況を追跡することを提供する。
  12. 12 月額サブスクリプションの代わりに、1回限りの従量課金リマインダー gemini-3.6-flash · rule breaker · 13/20点 (6 + 7) このアイデアは、月額19ドルという純粋なSaaSサブスクリプションモデルのソフトな制約を破る。5ドルの1回限りの料金で、延滞支払い記事の読者は、追跡リンクを含む法的に健全なリマインダーレターを送信してもらうことができ、後でサブスクリプションを契約した場合、その料金は全額クレジットされる。
  13. 13 ツールで開くテンプレート claude · within brief · 11/20点 (6 + 5) 投稿の請求書テンプレートを、ツール内のすぐに使える請求書として提供する。ワンクリックで、ファイルダウンロードではなく、事前入力されたトライアルアカウントが開く。
  14. 14 問題固有の離脱インテントと自動メールシーケンス gemini-3.6-flash · within brief · 8/20点 (4 + 4) 延滞支払い記事に離脱インテントポップアップを実装し、メールアドレスと引き換えに、支払いが遅れているクライアント向けの緊急メールテンプレートを提供する。自動化された3部構成のメールシーケンスは、自動化されたワークフローが延滞支払いをどのように減らすかを受動的に説明し、トライアルアカウントにリンクする。

Kiratとブレインストーム：この一度きりのショップ再構築を、クライアントが実際に望むケアプランに変えるにはどうすればよいか？

kirat_brainstorm が評議会に質問した

評議会は15のアイデアを考え出し、それぞれを匿名で評価した。トップ3：

  1. 予算削減：ローンチ前の華やかさの前の運用（18/20点）
  2. CSV製品ゲートキーパー（17/20点）
  3. 信頼性配当（17/20点）

舞台裏

kirat_brainstorm ClaudeがKiratに送信するもの

記録日 2026-10-13 · KIRAT_BRAINSTORM · 労力：標準 · 15のアイデア · 1ラウンド · $0.10

トピック： 小規模なデジタルエージェンシーが、一度きりのショップ再構築を、クライアントが実際に望む継続的なケアリテーナーに変えるためのアイデア

送信されたコンテキスト： 4人のエージェンシー。クライアントはドイツ、オーストリア、スイスで約1,800の家具製品を販売しており、スタッフは3人、社内開発者はおらず、年間売上は約120万ユーロ。古い自社ホストのWooCommerceショップには31のプラグインがあり、昨年は2件のセキュリティインシデントがあった。クライアントはメンテナンスの削減と緊急事態の減少を望んでいる。地元のERPは製品データをCSVとしてエクスポートする。再構築予算：25,000ユーロ。ハード制約：ロックインなし。クライアントはいつでもすべてのデータとアクセスを持って離脱できなければならない。ハード制約：エージェンシーでの追加採用なし。

評議会の結果

  1. 1 予算の壁を破る：ローンチ前の運用を説明する提案 gpt-5.6 · ルール破り · 18/20点（9 + 9） このアイデアは、25,000ユーロの再構築予算というソフト制約を意図的に破るものです。提案内容は、例えば、意図的に最小限の構成でローンチするための22,000ユーロに加え、初年度の運用を確約するための12,000ユーロです。その代わりに、初期プロジェクトからは贅沢な機能を削除し、代わりにインポートの堅牢化、復元訓練、モニタリング、毎月の改善に資金を充てます。総額が高くなるのは、クライアントが、実際の運用コストがローンチ後にしか見えない一見完成したショップを再び購入することがないためです。すべてのアクセス認証情報、データ、作業成果物は、いつでも移転可能なままです。
  2. 2 CSVプロダクトゲートキーパー gpt-5.6 · ブリーフ内 · 17/20点（9 + 8） 毎回のERPインポートの前に、自動化されたパイプラインがCSVをチェックし、価格の欠落、重複、無効なバリアント、画像エラー、DACH圏の税務ロジック、不審な在庫変動を検出します。月額リテイナーには、ルールのメンテナンス、インポートのモニタリング、3人の従業員向けのわかりやすいエラーレポートが含まれます。これにより、技術的なメンテナンスが直接的なビジネス上の利益に変わります。誤った商品、フォローアップの質問、購入放棄が減ります。
  3. 3 信頼性配当 gpt-5.6 · ブリーフ内 · 17/20点（8 + 9） クライアントは、モニタリングとメンテナンスに対して適度な基本料金を支払います。追加の四半期ごとの金額は、インポートの成功、復元のテスト、応答時間などの合意された信頼性目標が達成された場合にのみ発生します。エージェンシーが原因で回避可能な停止が発生した場合、請求可能な緊急時間ではなく、サービス・クレジットが発生します。このモデルは、経済的インセンティブを予防に合わせ、エージェンシーが問題から利益を得るというクライアントの懸念を取り除きます。
  4. 4 終了準備完了ケア憲章 gpt-5.6 · ブリーフ内 · 16/20点（9 + 7） リテイナーは、意図的にロックイン防止製品として販売されます。モニタリング、アップデート、バックアップ、セキュリティチェック、毎月2つの小さな変更が、約1,200〜1,500ユーロで含まれます。すべてのアカウントはクライアントが保有し、コードとインポートスクリプトはクライアントのリポジトリに置かれます。毎月、クライアントはドキュメント、データエクスポート、いつでも解約できるハンドオーバーパックも受け取ります。これにより、クライアントは依存ではなく、実証可能な運用性に対して支払うことになります。
  5. 5 季節リリーストレイン gpt-5.6 · ブリーフ内 · 16/20点（8 + 8） 任意のサポートチケットの代わりに、年に4回の計画可能なコマースリリースがあります。例えば、ガーデンファニチャー、夏の終わり、ブラックウィーク、クリスマスなどです。各リリースには、小さなUXまたはマーチャンダイジングパッケージ、回帰テスト、その間の技術的なメンテナンスがリテイナーに含まれます。これにより、クライアントは目に見える継続的な開発を得られ、4人体制のエージェンシーにとって作業をまとめやすくなります。
  6. 6 四半期ごとの脱出テスト gpt-5.6 · ブリーフ内 · 16/20点（9 + 7） 四半期に一度、エージェンシーは製品、顧客、注文、コンテンツデータの完全なエクスポートを提供し、中立なテスト環境で文書化された再起動を実行します。クライアントが支払うのは、定期的に証明された脱出可能性、つまりアクセスリスト、復元ログ、ハンドオーバーマニュアルがクライアントに属することです。これにより、ロックインなしという厳格な基準が、反対意見からリテイナーの珍しいセールスポイントに変わります。
  7. 7 ケア憲章プラス成長交換 gpt-5.6 · 隣接 · 16/20点（8 + 8） 終了準備完了ケア憲章の小さな変異として、含まれる変更時間は事前に固定されず、運用、データ品質、コンバージョン改善の間で毎月シフトされます。未使用のボリュームは、最大1四半期繰り越せます。30分の共同ボードが、リスクと収益機会に基づいてその使用方法を決定します。リテイナーは終了準備完了のままですが、保険というよりは、柔軟な外部デジタルチームのように感じられます。
  8. 8 ERP同期＆カタログ安全リテイナー gemini-3.6-flash · ブリーフ内 · 13/20点（7 + 6） エージェンシーは、ローカルERP CSVとオンラインショップ間のインターフェースの継続的なモニタリングとメンテナンスを引き受けます。誤ったデータインポート、家具バリアントの欠落、間違った価格は、公開される前に自動的に検出されます。これにより、データメンテナンスの運用負担がクライアントの3人チームから完全に取り除かれます。
  9. 9 AI搭載製品データ強化フラットレート gemini-3.6-flash · 隣接 · 13/20点（6 + 7） ERPインターフェースアイデアの変異：エージェンシーはCSVインポートを維持するだけでなく、AIスクリプトを使用して、生データを構造化属性、SEOコピー、DACH固有の配送時間メモで自動的に強化します。これにより、クライアントの手動メンテナンス作業が節約され、追加のエージェンシースタッフなしで家具市場での可視性が向上します。
  10. 10 CI/CDベースのビジュアル回帰メンテナンス契約 gemini-3.6-flash · ブリーフ内 · 12/20点（6 + 6） リスクの高いライブアップデートの代わりに、エージェンシーは、毎月のプラグインアップデートを視覚的かつ機能的に自動チェックするステージングパイプラインを設定します。クライアントは、毎月の透明性レポートと、セキュリティ脆弱性に対する保証された応答時間を受け取ります。これにより、これまでの緊急事態なしに絶対的な安定性が保証されます。
  11. 11 四半期ごとのコンバージョン＆UX磨き gemini-3.6-flash · ブリーフ内 · 11/20点（6 + 5） 基本メンテナンスに加えて、リテイナーには、チェックアウト機能と家具バリアント表示の最適化のための固定時間枠が含まれます。エージェンシーは毎月DACH地域のユーザー行動を分析し、高いリターンをもたらす調整を実装します。これにより、リテイナーは純粋なコスト要因から収益ドライバーに変わります。
  12. 12 安全なアップデート＆即時ロールバック保証 gemini-3.6-flash · 隣接 · 11/20点（5 + 6） CI/CDメンテナンス契約の変異：リテイナーは、インシデント発生時に15分以内の自動スナップショット復元を備えた、保証されたゼロダウンタイムSLAに純粋に焦点を当てています。これは、2つのセキュリティインシデント後のクライアントの懸念に、最小限の継続的な手動作業で直接対応します。
  13. 13 固定予算の代わりに収益シェア成長パッケージ gemini-3.6-flash · ルール破り · 9/20点（4 + 5） 25,000ユーロの固定再構築予算というソフトな前提を破ります。再構築コストは10,000ユーロに削減され、月額リテイナーと追加収益の小さなシェアが組み合わされます。これは、クライアントが投資リスクを下げ、エージェンシーが120万ユーロのショップの成長に直接参加するため、価値があります。
  14. 14 ヘッドレスアーキテクチャケアサービス gemini-3.6-flash · ルール破り · 7/20点（3 + 4） 従来のモノリス構成（標準的なWooCommerceなど）のソフト制約を破ります。フロントエンドがバックエンドから分離されているため、プラグインのセキュリティ脆弱性がウェブサイトを直接攻撃できなくなります。これは、緊急事態が構造的に排除され、オープンソーススタックと完全なGitアクセスにより、クライアントがいつでも移植可能なままであるため、価値があります。
  15. 15 毎月の1ページケアレポート claude · ブリーフ内 · 6/20点（4 + 2) アップタイム、ページ速度、適用されたアップデート、防止されたインシデントを含む毎月の1ページレポート。これにより、クライアントはリテイナーが何に対して支払っているかを確認できます。

私たちの新しい注文ページは来月公開されます。Kiratと一緒に、有料広告なしでケーキの予約注文を増やす方法をブレインストーミングしましょう。

kirat_brainstorm が評議会に質問しました

評議会は15のアイデアを考案し、それぞれを匿名で評価しました。トップ3：

  1. 毎年の誕生日オートパイロット（18/20点）
  2. 一般的な投稿の代わりに実際のケーキスロット（17/20点）
  3. ケーキ自体が広告媒体として旅する（16/20点）

舞台裏

kirat_brainstorm ClaudeがKiratに送信するもの

記録日 2026-10-13 · KIRAT_BRAINSTORM · 労力: 標準 · 15のアイデア · 1ラウンド · $0.09

トピック: 地元のベーカリーが、新しいオンライン注文ページを通じて、有料広告なしでカスタムケーキの予約注文を増やすためのアイデア

送信されたコンテキスト: ドイツの人口4万人の町にある、スタッフ6人のベーカリー。カスタムケーキと予約注文は最も利益率が高い。新しいオンライン注文ページ（ケーキの選択、受け取り日、前払い）は来月公開予定。これまでは注文は電話とメールのみだった。Googleビジネスプロフィールは、120件のレビューで4.7つ星。オーナーは時間がほとんどないため、アイデアは週に最大2時間で実行できるものでなければならない。ハード制約：今四半期は有料広告なし。ハード制約：追加スタッフなし。

評議会の結果

  1. 1 毎年恒例の誕生日オートパイロット gpt-5.6 · 制約内 · 18/20点 (9 + 9) チェックアウト時に、顧客は任意で機会と月を残し、翌年にリマインダーを受け取ることができます。21日前に自動メールが送信され、事前入力済みの注文ページへ誘導します。これにより、継続的な顧客獲得なしで、クリーンな同意のもと、すべての注文が将来の注文を生み出します。
  2. 2 一般的な投稿ではなく、実際のケーキ枠を表示 gpt-5.6 · 制約内 · 17/20点 (9 + 8) 注文ページには、今後4週間の実際の残り生産枠が表示されます（例：「土曜日はあと2件のオーダーメイドケーキが可能です」）。毎週のGoogleビジネス投稿は、このビューに直接リンクします。更新と投稿を合わせても最大20分で完了し、割引なしで信頼できる緊迫感を生み出します。
  3. 3 ケーキ自体が広告媒体として旅をする gpt-5.6 · 制約内 · 16/20点 (8 + 8) 受け渡しされるすべてのケーキに、「このケーキを再注文またはカスタマイズ」と書かれた小さなカードと、対応するバリエーションへのQRコードが付けられます。カードはケーキがカットされる際に目立つように表示されるため、その場にいる誕生日や結婚式のゲストが正確に注文方法を見つけられます。一度作成したカードセットは、毎週の手間がほとんどかかりません。
  4. 4 ローンチ時の1回限りのケーキ相談時間 gpt-5.6 · ルール破り · 16/20点 (8 + 8) ローンチ後の最初の土曜日に、4時間のオープンなケーキ相談時間が設けられます。ゲストはサンプルカードからフレーバーとスタイルを選び、その場に置かれたQRコードを使って自分で注文します。これは、その週の作業時間を最大2時間とするソフト制約を意図的に破ります。追加の労力は、実際の注文、観察されたユーザビリティの問題、再利用可能な写真や顧客の質問がすべて同時に生み出されるため、報われます。追加スタッフや有料広告は不要です。
  5. 5 インフルエンサーではなく、機会パートナー gpt-5.6 · 制約内 · 15/20点 (8 + 7) 子供向け遊び場、写真家、フラワーショップ、結婚式場、クラブハウスにはそれぞれ、その機会に合わせて事前設定されたケーキ選択に導く小さなQRスタンドが配布されます。その見返りとして、ベーカリーは地元のおすすめページでこれらのパートナーを紹介します。月に5件のターゲットを絞ったリクエストで十分であり、手数料や有料リーチは不要です。
  6. 6 オフィスとクラブ向けのケーキ当番表 gpt-5.6 · 制約内 · 15/20点 (8 + 7) 地元のオフィス、診療所、クラブ向けに、複数の誕生日や定期的な日付をまとめて、前払いで順番に登録できるページが用意されます。一度設定された四半期ごとの当番表は、個々の機会を計画可能な一連の注文に変えます。アウトリーチは週に2組織に限定できます。
  7. 7 カウンタータブレットでのハイブリッドケーキ相談 gemini-3.6-flash · ルール破り · 14/20点 (7 + 7) 金曜日に1時間の店舗内相談を提供することで、「オンライン注文のみ」というソフト制約を意図的に破り、その際にタブレットで一緒に注文を入力します。決断が難しい顧客や年配の顧客が、新しいオンラインシステムに徐々に慣れるため、効果があります。
  8. 8 レビューが意思決定の助けになる gpt-5.6 · 隣人 · 13/20点 (7 + 6) 最も強力な既存素材の小さな再結合として、120件のGoogleレビューから意味のある12の文章が、一致するケーキスタイルとペアになり、それぞれに直接注文リンクが付けられます。これにより、4.7スターは単なる信頼シグナルとして表示されるだけでなく、商品選択に役立ちます。一度設定すれば、ページはほとんどメンテナンスフリーです。
  9. 9 サンプルケーキの展示とショップのディープリンク gemini-3.6-flash · 隣人 · 13/20点 (6 + 7) 販売室で最も美しいケーキの物理的なフォトギャラリーには、各写真に特定のQRコードが含まれており、オンラインショップで事前選択されたこの正確なケーキモデルが開きます。アイデア1の変異：店舗内ディスプレイとショップの直接ディープリンクをリンクします。
  10. 10 Googleプロフィールの最適化と自動レビューリンク gemini-3.6-flash · 制約内 · 12/20点 (6 + 6) 強力なGoogleプロフィール（4.7スター）には、公式の「オンラインで注文」ボタンが追加され、現在のケーキの写真で毎週更新されます。受け取り時に、顧客はレビューと再注文ページへのリンクを含むテンプレートをメールで受け取ります。毎週30分未満で完了します。
  11. 11 レシートとパン袋のQRコードティーザー gemini-3.6-flash · 制約内 · 11/20点 (6 + 5) 目を引くQRコードがすべてのレシートとパッケージに印刷され、オンラインのケーキコンフィギュレーター（「お祝いのためのドリームケーキをオンラインで計画」）に直接つながります。これにより、カウンターでの追加の手間なしに、毎日の来店客をデジタル事前注文者に変えます。
  12. 12 地元のイベント会場とのB2Bパートナーシップ gemini-3.6-flash · 制約内 · 11/20点 (6 + 5) ウェブサイトへの直接予約コードが記載されたスタンドとチラシが、地元のレストラン、イベントバーン、ウェディングプランナーに置かれます。祝う顧客は直接オンラインでケーキを予約し、会場はその見返りに少額の経費手当または紹介を受け取ります。
  13. 13 保育園と学校の誕生日カレンダー gemini-3.6-flash · 隣人 · 10/20点 (4 + 6) 子供向けテーマケーキ用の固定割引コードを含む保護者会向け情報チラシを通じて、地元の幼稚園と協力します。アイデア3の変異：一般的なB2Bパートナーではなく、子供の誕生日という高頻度の機会に、自動化された方法で特に対応します。
  14. 14 デコレーションケーキの毎月ミニワークショップ gemini-3.6-flash · ルール破り · 10/20点 (4 + 6) 月に1回4時間のワークショップが開催されるため、「週最大2時間」というソフト制約を意図的に破ります。参加者はブランドアンバサダーとして行動し、熱心なソーシャルメディアコンテンツを作成し、オンラインショップ経由でフォローアップ注文を確実に行うため、効果があります。
  15. 15 すべてのケーキボックスに注文リンク claude · 制約内 · 8/20点 (4 + 4) ケーキボックスとレシートに注文ページへのQRコードを印刷し、すでにケーキを購入したすべての顧客が、電話なしで次の誕生日に再注文できるようにします。

KiratからClaudeへのメモ： 最良のルール破りアイデアは4位のみ：「ローンチ時の1回限りのケーキ相談時間」— これはソフト制約を意図的に破っています。破棄する前に一度、最善の形で擁護してください。

Kiratとブレインストーミングして、請求をモノリスから分離せずに、2四半期以内に請求インシデントを削減する方法を考えましょう。

kirat_brainstorm が評議会に質問しました

評議会は15のアイデアを考案し、それぞれを匿名で評価しました。上位3つ：

  1. 請求テーブル周りのデータベースファイアウォール (17/20点)
  2. 実行可能な財務不変条件 (17/20点)
  3. インシデントリプレイをリリース関門として使用 (17/20点)

舞台裏

kirat_brainstorm ClaudeがKiratに送信するもの

記録日 2026-10-13 · KIRAT_BRAINSTORM · 労力: 標準 · 15アイデア · 1ラウンド · $0.06

トピック: 請求モジュールによって引き起こされる本番インシデントを、別のサービスに抽出せずに2四半期以内に削減するアイデア

送信されたコンテキスト: 8人のエンジニアからなるチーム。約60,000行のTypeScriptモノリス1つ、Postgresデータベース1つ、1日数回デプロイ。請求モジュールは毎週変更され、過去8件の本番インシデントのうち5件を引き起こしており、そのほとんどは他のモジュールが請求テーブルを直接読み書きすることによるものです。チームの誰も本番環境で分散システムを運用した経験がありません。リーダーシップは2四半期以内にインシデントを減らしたいと考えています。ハード制約：請求モジュールの書き換えはしない。ハード制約：請求に関する機能作業は毎週継続する。

評議会からの結果

  1. 1 請求テーブル周りのデータベースファイアウォール gpt-5.6 · ブリーフ内 · 17/20点 (9 + 8) モノリスの請求コードパスと非請求コードパス用に別々のPostgresロールを作成し、一般アプリケーションロールから請求テーブルへの直接書き込みを禁止します。すべての変更を、レビュー済みの少数のストアドプロシージャまたはトランザクション関数を通してルーティングし、まず一時的な監査ログを追加して、毎週の機能開発を止めずに呼び出し元を発見・移行します。
  2. 2 実行可能な財務不変条件 gpt-5.6 · ブリーフ内 · 17/20点 (9 + 8) 確定済み請求書の不変性、整合性のある台帳エントリ、冪等な課金作成、有効な状態遷移などの短い不変条件リストを、安全な場合はデータベース制約として、そうでない場合はスケジュールされた本番プローブとしてエンコードします。同じプローブをCIの匿名化された本番形状フィクスチャに対して実行し、インシデントの知識を広範なテスト拡張ではなく恒久的なトリップワイヤーに変換します。
  3. 3 リリース関門としてのインシデントリプレイ gpt-5.6 · ブリーフ内 · 17/20点 (9 + 8) 5つの請求インシデントを、キャプチャされたクエリ形状とサニタイズされた行を使用して決定的なリプレイシナリオに変換し、すべての請求変更がそれらを生き残ることを要求します。それらの正確なシナリオの周りで、リトライ、重複イベント、トランザクション順序、部分的な失敗を並べ替える生成テストを追加し、モノリスの網羅的なカバレッジを試みるのではなく、障害の近傍をターゲットにします。
  4. 4 請求境界のシャドウ強制 gpt-5.6 · 隣接 · 16/20点 (9 + 7) データベースファイアウォールの低リスクな変形として、現在の権限を最初は維持しつつ、請求テーブルに触れるすべてのクエリを、そのモジュール、コールサイト、トランザクションIDとともにログに記録します。4週間後、予期しない書き込みをCI失敗に変え、その後モジュールごとに本番エラーにします。これにより、即時の権限切り替えではなく、段階的な強制を代替します。
  5. 5 請求ブラスト半径スイッチボード gpt-5.6 · ブリーフ内 · 16/20点 (9 + 7) モジュール全体ではなく、リスクの高い請求動作をサーバーサイドのキルスイッチとパーセンテージロールアウトの背後に置き、請求書、支払い、照合の異常にキー付けされたダッシュボードを用意します。毎週の機能はテスト済みのオフパスとともに出荷され、対応者が無関係なモノリスデプロイをリバートしたりスキーママイグレーションを元に戻したりせずに新しい動作を無効化できるようにします。
  6. 6 Postgresスキーマのカプセル化と行レベルセキュリティ gemini-3.6-flash · ブリーフ内 · 15/20点 (7 + 8) 請求テーブルを専用のPostgresスキーマ（billing.*）に分離し、他のDBロールからの直接の書き込みおよび読み取りアクセスを禁止します。モジュールは定義されたSQLビューまたはストアドインターフェースを介してのみアクセスします。これにより、インシデントの主な原因をデータベースレベルで直接排除します。
  7. 7 請求リリースのためのコントラクトテストとシャドウパイプライン gemini-3.6-flash · ブリーフ内 · 15/20点 (8 + 7) CIパイプライン内のすべての請求インターフェースに対して、自動化されたコンシューマー駆動のコントラクトテストを確立します。さらに、重要な計算への請求変更は、副作用なしで自動差分チェック付きのシャドウモードで本番実行されます。
  8. 8 安全装置としてのセカンドデータベース gpt-5.6 · ルール破り · 14/20点 (7 + 7) 「1つのPostgresデータベース」というソフトな前提を意図的に破り、論理レプリケーションを通じて供給される読み取り専用シャドウデータベースを追加しつつ、請求をモノリス内に維持し、プライマリを唯一の書き込み元として保持します。新しい請求読み取りと照合チェックを両方のデータベースに対して実行し、公開前に結果を比較し、シャドウをフォレンジッククエリに使用して、インシデント診断が本番を過負荷にしたり誤って変更したりしないようにします。
  9. 9 厳格なモジュール境界リンティングと公開APIファサード gemini-3.6-flash · ブリーフ内 · 14/20点 (7 + 7) dependency-cruiserを介したアーキテクチャリンティングを導入し、ビルドステップで他のモジュールが請求内部を直接インポートすることを禁止します。通信は単一の型安全なBillingFacadeインターフェースを介してのみ行われるため、忍び寄る結合は即座にブロックされます。
  10. 10 請求変更パスポート gpt-5.6 · ブリーフ内 · 13/20点 (7 + 6) すべての請求関連プルリクエストに、影響を受けるテーブル、不変条件、マイグレーション互換性、ロールバックパス、デプロイ後の健全性を証明する1つの本番クエリを含む、機械チェック済みのパスポートを要求します。CODEOWNERSゲートと15分の交代制請求スチュワードレビューにより、プロセスを毎週の変更に十分軽量に保ちつつ、クロスモジュール効果に精査を集中させます。
  11. 11 外部モジュール用の自動生成読み取り専用Postgresビュー gemini-3.6-flash · 隣接 · 13/20点 (7 + 6) スキーマカプセル化の変形：コストのかかるAPIリファクタリングの代わりに、外部クエリ用に読み取り専用のPostgresビューが自動的に提供されます。外部モジュールはこれらの安定したビューのみを読み取り、直接のテーブルアクセスはDB権限でブロックされます。
  12. 12 読み取りモデルのための非同期インプロセスイベントバス gemini-3.6-flash · ブリーフ内 · 12/20点 (4 + 8) 他のモジュールが請求テーブルを直接クエリする代わりに、請求モジュールは状態変更時にインメモリイベントを送信します。受信モジュールは独自のローカルプロジェクションを構築します。これにより、分散システムを導入せずに請求テーブルからの読み取りアクセスを完全に分離します。
  13. 13 請求カプセル化のための2週間の機能凍結 gemini-3.6-flash · ルール破り · 11/20点 (5 + 6) 継続的な毎週の機能出力というソフトな制約を、ちょうど2週間破ります。チーム全体がDB結合の分離に集中します。この一度きりの取り組みは、残り5か月でインシデント数を持続的に削減するための基盤を築きます。
  14. 14 モジュールごとのデータベースロール claude · ブリーフ内 · 11/20点 (6 + 5) 請求に独自のPostgresスキーマとロールを与え、他のモジュールの請求テーブルへの書き込みアクセスを禁止し、直接書き込みが本番に到達する前にステージングで失敗するようにします。
  15. 15 2番目のPostgresインスタンスへの物理的DBパーティショニング gemini-3.6-flash · ルール破り · 9/20点 (3 + 6) 単一データベースアーキテクチャのソフトな制約を破りますが、モノリシックコードは維持します。請求データは独自のデータベースインスタンスに移動し、横断的なSQL結合を技術的に不可能にします。コードがモノリシックのままであるため、運用の複雑さは最小限に保たれます。

KiratからClaudeへのメモ: 最良のルール破りアイデアはランク8のみ：「安全装置としてのセカンドデータベース」— これはソフトな制約を意図的に破ります。破棄する前に一度だけ鋼鉄化してください。

Kiratとブレインストームして、約3,000件のレコードのスクリーニング時間をレビューの厳格さを弱めずに削減する方法を考えましょう。

kirat_brainstorm が評議会に尋ねた

評議会は14のアイデアを出し、それぞれを匿名で評価しました。上位3つ：

  1. 二人の人間による除外ゲート (18/20点)
  2. エッジケース台帳を使ったキャリブレーションスプリント (16/20点)
  3. ミニチュアデータ抽出ではなく高速バイナリコンソール (15/20点)

舞台裏

kirat_brainstorm ClaudeがKiratに送るもの

記録 2026-10-13 · KIRAT_BRAINSTORM · 労力: 標準 · 14アイデア · 1ラウンド · $0.18

トピック: 約3,000件のレコードのタイトルと要旨のスクリーニングにかかるスタッフ時間を、系統的レビューの厳格さを弱めずに削減するアイデア

送信されたコンテキスト: 出版予定の医療サービス研究における系統的レビュー。現在のプロトコル：2人の独立した人間のスクリーナー、紛争は話し合いで解決。スタッフ時間が不足しています。ジャーナルのレビュアーはスクリーニングがどのように行われたかを尋ねます。関連研究の見逃し（誤除外）は、無関係なものを含めることよりも悪いです。ハード：方法はPRISMA 2020に基づいて報告可能でなければなりません。ハード：誤除外の率は増加してはなりません。

評議会からの結果

  1. 1 二人の人間による除外ゲート gpt-5.6 · ルール破り · 18/20点 (10 + 8) レビューアAにすべてのレコードをスクリーニングさせるが、Aの「含める」判断と「不確か」な判断はそのまま先に進める。レビューアBは、Aが提案した除外候補のみを独立して評価する。両方の人間が独立して除外した場合のみレコードを除外し、意見が分かれたものはすべて自動的に先へ進めることで、ほとんどの衝突議論を排除する。これは、二人の人間がすべてのレコードを評価しなければならないという現在のプロトコルの暗黙の前提を意図的に破るものである。スクリーニング時間を節約しつつ、構造的に偽陽性（誤って含めること）は増えるが偽陰性（誤って除外すること）は増えないため、価値がある。また、PRISMAの選定プロセス欄で説明するのも簡単である。
  2. 2 エッジケース台帳を使ったキャリブレーションスプリント gpt-5.6 · 指示内 · 16/20点 (9 + 7) 層別化した最初のバッチを独立して二重スクリーニングし、衝突を解決し、繰り返し発生する曖昧さを、肯定的・否定的な例を添えた短い運用ルールに変換する。続行する前にルールを確定させる。パイロット判断は、適格性基準が変更されなかった場合のみ保持し、変更された場合は再スクリーニングする。これにより、二人の独立したスクリーニングを維持しつつ、後の審議や衝突解決の時間を削減でき、キャリブレーションはPRISMAに基づいて報告できる。
  3. 3 高速な二値コンソール（簡易データ抽出ではない） gpt-5.6 · 指示内 · 15/20点 (8 + 7) 両方のレビューアに、完全なタイトルと要約が常に表示される、キーボード操作のみで「含める」「除外する」「不確か」の3択に限定した盲検インターフェースを提供する。詳細なコーディングや除外理由はフルテキストレビューに先送りする。PRISMA 2020は、タイトル・要約段階でのレコード単位の理由を要求していない。判断プロセスは変わらないが、避けられる読書、クリック、文書化作業の時間が短縮される。
  4. 4 包含専用の機械リリースバルブ gpt-5.6 · 隣接案 · 15/20点 (9 + 6) 二人の人間による除外ゲートの一段階変異として、Aが提案した除外候補を、レコードを包含にのみ解放し決して除外しない検証済み分類器にかける。レビューアBは、分類器が解放しなかったすべてのものを独立してスクリーニングする。最終的な除外には依然として二人の人間の一致した判断が必要なため、機械のエラーはフルテキストを追加することはあっても、誤った除外を生み出すことはない。モデル、バージョン、入力、閾値、検証、および厳密に包含専用であるという役割をPRISMAに基づいて報告する。
  5. 5 非対称除外スクリーニング gemini-3.6-flash · 指示内 · 15/20点 (7 + 8) 最初のレビューアが3,000件すべてのレコードを完全に分類する。2番目のレビューアは、最初のレビューアが除外したレコードのみをチェックし、偽陰性（見落とし）を捕捉する（「含める」判断は直接受け入れられる）。これにより、2番目のレビューアの労力はほぼ半分になり、誤った除外のリスクを極めて低く抑えつつ、すべてのPRISMA要件を満たす。
  6. 6 高収量層のスクリーニング迂回 gpt-5.6 · ルール破り · 13/20点 (8 + 5) 高収量のサブセット（高度に特化した検索ブロックからのレコード、既知の適格研究の直接の引用文献、密接に関連するレビューに既に含まれているレコードなど）を事前に宣言し、タイトル・要約の判断なしにそれらすべてを直接フルテキスト取得に送る。これは、それらのレコードについて、ソフトな二人スクリーナー方式を意図的に破るものだが、サブセット内の何も除外されないため、誤った除外を増やすことはない。トレードオフは、フルテキスト作業の追加である。迂回ルールと結果の件数を、PRISMAフロー図と選定方法に明示的に報告する。
  7. 7 能動学習による優先順位付けスクリーニング gemini-3.6-flash · 指示内 · 13/20点 (5 + 8) 両方の人間のスクリーナーが、関連するタイトル/要約を上位に並べる能動学習ツール（ASReviewなど）を使用する。統計的に検証された停止基準（例：関連性のないヒットが500件連続）に達した時点で、スクリーニングを終了する。この手順は最大70%の時間を節約でき、PRISMA 2020準拠の方法で文書化でき、アルゴリズムのキャリブレーションを通じて最小限の誤った除外率を維持する。
  8. 8 スクリーニング前の完全一致のみの重複排除 gpt-5.6 · 指示内 · 12/20点 (8 + 4) DOI、データベースのアクセッション番号、または正確に正規化された書誌マッチングによって同一であることが証明されたレコードのみを削除し、メタデータが最も豊富なコピーを保持し、不確かな類似重複にはフラグを付けるだけにする。その後、両方のレビューアが残りのすべての一意なレコードを独立してスクリーニングし、PRISMAはスクリーニング前に削除された重複を報告する。これにより、一意な研究を除外する経路を作らずにボリュームを削減できる。
  9. 9 AIセーフティネット付き人間-AIカスケード gemini-3.6-flash · 隣接案 · 12/20点 (5 + 7) 非対称除外スクリーニングの変異：一人の人間のスクリーナーがすべてのレコードを単独で処理し、最大感度に調整されたAIモデルが人間の除外のみをチェックする。二人目の人間は、不一致がある場合のみチェックする。これにより、完全なカバレッジを維持しながら、人間のキャパシティを50%以上削減できる。
  10. 10 完全自動化されたAIセカンドレビューア gemini-3.6-flash · ルール破り · 11/20点 (3 + 8) 二人の人間がスクリーニングを行わなければならないというソフトな制約を破る。大規模言語モデル（LLM）が、偽陰性ゼロのプロンプトで独立したセカンドレビューアの役割を担う。人間の作業時間が半分になり、LLMが抄録スクリーニングで高い再現率を達成できることが示されているため、価値がある。PRISMA 2020はAIツールの報告を明示的に許可している。
  11. 11 信頼度トリアージ付きリスク適応型シングルスクリーニング gemini-3.6-flash · ルール破り · 11/20点 (5 + 6) データセット全体に対する継続的な二重スクリーニングというソフトな制約を破る。最初のレビューアが主観的な高い信頼度を示し、明確な除外理由が存在する場合、二人目のレビューアは省略され、不確かなケースのみが二重スクリーニングに進む。これにより、スタッフ時間を最大60%節約できる一方、リソースがグレーゾーンに集中するため、研究の見逃しリスクは最小限に抑えられる。
  12. 12 最初にキャリブレーションラウンド claude · 指示内 · 11/20点 (6 + 5) 両方のスクリーナーが同じ100件のレコードをスクリーニングし、すべての衝突について議論し、本番ラウンドの前に適格性基準を明確化する。これにより、後の衝突や再読込が減少する。
  13. 13 AIトリアージ付き二値化高速スクリーニング gemini-3.6-flash · 隣接案 · 10/20点 (4 + 6) 能動学習による優先順位付けの変異：チームは簡素化されたインターフェース（「含める/不確か」対「除外する」のクリックのみ）を使用して迅速な評価を行う。AIモデルがバックグラウンドで不確実性を評価し、境界線上の候補のみを詳細な二重チェックに送る。これにより、抄録あたりの認知負荷と読書時間を劇的に最小化する。
  14. 14 マッチングアルゴリズムによる決定的事前フィルタリング gemini-3.6-flash · 指示内 · 6/20点 (3 + 3) 保守的な検索フィルターとスクリプトが、明らかに不適切なヒット（例：誤った研究デザインや非ヒト集団）を事前に選別する。両方のスクリーナーは、これらの自動除外を代表サンプル（例：10%）のみチェックする。これにより、手動スクリーニングが必要な総量を、感度を損なうことなくPRISMA準拠の方法で削減できる。

すべてのアイデア、完全な形でランク付けされたもの。Claude自身のアイデアも匿名で対等な条件で参加する。トピックとコンテキストは英語で送信された。メンバーがドイツ語で書いたアイデアはここで翻訳されている。

さまざまな分野からの5つの見出しとタイトル。各メンバーが1つのバリアントを書き、Claudeのドラフトも参加し、両メンバーが3つすべてを匿名で評価する。1つを選ぶ。

Kiratに私の価格ページ用の見出しバリアントを書かせてください。最大8語、最上級表現なし。

kirat_create が評議会に尋ねた

勝利バリアント（17/20点）： 「Wordなしで支払いを受ける—14日間無料」

私自身のドラフトは2位だった。メンバーは3つすべてを匿名で評価した。

舞台裏

kirat_create ClaudeがKiratに送るもの

記録日 2026-10-13 · KIRAT_CREATE · モード: VARIANTS · 労力: STANDARD · $0.03

ブリーフ: フリーランサー向けの小規模な請求書作成ツールの価格ページ用見出し（月額19米ドル、14日間無料トライアル）。対象者: 現在WordやExcelで請求書を作成しているフリーランサー。目標: トライアルをリスクフリーで価値があると感じさせること。形式: 英語で1つの見出し。

基準: 最大8語 · 具体的で、最上級表現なし · 節約できる時間または支払いの受け取りに言及 · 感嘆符なし

評議会の結果

  1. 1 「Wordなしで支払いを受ける—14日間無料」 gpt-5.6 · 17/20点 (9 + 8) Wordユーザーに直接語りかけ、支払いの受け取りを前面に押し出し、リスクフリーのトライアルを具体的にしている。
  2. 2 「数分で請求書を送信。期日通りに支払いを受け取る。」 claude · 17/20点 (8 + 9) オーケストレーター自身のドラフト。
  3. 3 「WordとExcelを置き換え。数日早く支払いを受け取る。」 gemini-3.6-flash · 14/20点 (7 + 7) 現在の手動ワークフローに直接言及することで即時の対比を提供し、一般的な誇大広告を使わずに、トライアルをキャッシュフローへの迅速でリスクフリーなアップグレードとして位置付けている。

KiratにWooCommerceの家具ショップ向けランディングページの見出しバリアントを書かせてください。最大10語、専門用語なし。

kirat_create が評議会に尋ねた

勝利バリアント（18/20点）： 「遅くてイライラするWooCommerceストアで家具の購入者を失っていませんか？」

私自身のドラフトは3位だった。メンバーは3つすべてを匿名で評価した。

舞台裏

kirat_create ClaudeがKiratに送るもの

記録日 2026-10-13 · KIRAT_CREATE · モード: VARIANTS · 労力: STANDARD · $0.02

ブリーフ: WooCommerceを運営する家具小売業者向けのショップ再構築に関する小規模デジタルエージェンシーのランディングページ用見出し。対象者: 社内開発者を持たない中規模の家具ショップのオーナー。目標: 無料ショップチェックの予約。形式: ドイツ市場向けだが英語で書く、1つの見出し。

基準: 最大10語 · エージェンシーではなく読者の痛みに言及 · 「ヘッドレス」や「オムニチャネル」などの専門用語なし · 最上級表現なし

評議会の結果

  1. 1 「遅くてイライラするWooCommerceストアで家具の購入者を失っていませんか？」 gemini-3.6-flash · 18/20点 (8 + 10) オーナーの主なフラストレーションである、ストアのパフォーマンス低下による売上損失に、技術的な専門用語や自己賛美的なエージェンシー言語を使わずに直接焦点を当てている。
  2. 2 「あなたのWooCommerceショップは家具の購入者を遠ざけていませんか？」 gpt-5.6 · 17/20点 (9 + 8) 中核的な痛みを直接挙げ、専門用語なしで家具小売業者に語りかけている。
  3. 3 「ショップの緊急事態を減らし、家具のための時間を増やす。」 claude · 11/20点 (7 + 4) オーケストレーター自身のドラフト。

Kiratにパン屋の新しいケーキ注文ページ用の見出しバリアントを書かせてください。短く、地域密着型で、チェーン店らしくないもの。

kirat_create が評議会に尋ねた

勝利バリアント（19/20点）： 「お祝いのケーキ、ここで焼いて、お渡しします。」

私自身のドラフトは3位だった。メンバーは3つすべてを匿名で評価した。

舞台裏

kirat_create ClaudeがKiratに送るもの

記録日 2026-10-13 · KIRAT_CREATE · モード: VARIANTS · 労力: STANDARD · $0.02

ブリーフ: 特注ケーキの新しいオンライン注文ページ用のパン屋の見出し。対象者: これまで電話で注文していた地域の顧客。目標: オンライン注文を簡単で親しみやすく感じさせること。形式: ドイツ市場向けだが英語で書く、1つの見出し。

基準: 最大8語 · 具体的で、最上級表現なし · 受け取りまたは機会（イベント）に言及 · チェーン店ではなく地元のパン屋らしく聞こえる

評議会の結果

  1. 1 「お祝いのケーキ、ここで焼いて、お渡しします。」 gpt-5.6 · 19/20点 (10 + 9) 温かみがあり、具体的で、個人的：「ここで焼いて」は地域密着感を感じさせ、「お渡しします」はオンラインプロセスを簡単に感じさせる。
  2. 2 「特注のバースデーケーキを注文、焼きたてで受け取り。」 gemini-3.6-flash · 16/20点 (8 + 8) 機会（イベント）と受け取りの両方を具体的に挙げ、新鮮さの約束を通じて、非人間的な決まり文句なしに地域の職人技を伝えている。
  3. 3 「あなたのケーキ、あなたの日付。2分で注文。」 claude · 9/20点 (5 + 4) オーケストレーター自身のドラフト。

Kiratに、モノリス内の請求境界を最初に強化するための私の提案のタイトルを見つけさせてください。

kirat_create が評議会に尋ねた

私自身のドラフトが勝利した（19/20点）： 「最初に請求の境界を修正し、必要なら後で分割する」

舞台裏 kirat_create ClaudeがKiratに送る内容

記録日 2026-10-13 · KIRAT_CREATE · モード: VARIANTS · 労力: STANDARD · $0.02

依頼内容: 社内エンジニアリング提案書のタイトル: モノリス内の請求モジュールの境界を強化してから、別サービス化を検討する。対象読者: インシデント削減を望むエンジニア8名とリーダー層。目的: 提案書を読まれ、承認されること。形式: 英語でタイトル1件。

評価基準: 最大10語 · テーマだけでなく意思決定を示すこと · バズワードなし · 非エンジニアにも理解可能であること

評議会の結果

  1. 1 "Fix billing's boundaries first, split it later if needed" claude · 19/20点 (10 + 9) オーケストレーター自身の草稿。
  2. 2 "Keep Billing Together, but Isolate It to Prevent Incidents" gpt-5.6 · 16/20点 (9 + 7) このタイトルは、請求機能をモノリスに残しつつ境界を強化するという意思決定を示し、それをインシデント削減という共通目標に結び付けている。
  3. 3 "Strengthen Billing Boundaries in Current App Before Splitting Service" gemini-3.6-flash · 13/20点 (7 + 6) このタイトルは方向性について明確な意思決定を示し、経営層向けに「モノリス」などの不要な専門用語を避け、安定性という共通目標に直接言及している。

LLMを追加スクリーナーとして用いる方法論ペーパーのタイトルをKiratに見つけてもらう。正確に、誇張なしで。

kirat_create 評議会に依頼

勝利したバリアント (18/20点): "Large Language Model–Assisted Study Selection in Health Services Research: A Method for Additional Screening in Systematic Reviews"

私自身の草稿は2位でした。メンバーは3件すべてを匿名で評価しました。

舞台裏

kirat_create ClaudeがKiratに送る内容

記録日 2026-10-13 · KIRAT_CREATE · モード: VARIANTS · 労力: STANDARD · $0.02

依頼内容: 医療サービス研究における系統的レビューでLLMを追加スクリーナーとして用いる方法論ペーパーのタイトル。対象読者: 研究者とジャーナル査読者。目的: 正確で引用可能なもの、誇張なし。形式: 英語でタイトル1件、コロンの後にサブタイトルを付けてもよい。

評価基準: 最大20語 · 方法と設定を明記すること · データを超える主張をしないこと · 「革命」などの誇張語を使わないこと

評議会の結果

  1. 1 "Large Language Model–Assisted Study Selection in Health Services Research: A Method for Additional Screening in Systematic Reviews" gpt-5.6 · 18/20点 (9 + 9) このタイトルは、スクリーニング方法、系統的レビューの文脈、医療サービス研究の設定を特定しつつ、性能や利点を示唆していない。
  2. 2 "An LLM as additional screener: a prospective comparison in a health services systematic review" claude · 16/20点 (9 + 7) オーケストレーター自身の草稿。
  3. 3 "Large Language Models as Auxiliary Screeners in Health Services Research Systematic Reviews: A Methodological Evaluation" gemini-3.6-flash · 15/20点 (7 + 8) このタイトルは応用分野と方法論を正確に示し、トリガーワードを避け、科学出版の文脈に適した事実に基づく引用可能なトーンを選んでいる。

見出しとタイトルは、依頼内容が求めた通り、英語のまま記載されている。Claudeのエントリにおける推論は、Kirat自身が付けたラベルである。ドイツ語で書かれた推論はここで翻訳されている。

異なる分野からの5つの画像依頼。OpenAIとGoogleがそれぞれ1枚ずつ画像を生成し、両メンバーが両方の画像を匿名で評価する。1つを選ぶ。

請求ツールのランディングページ用のヒーロー画像をKiratに作成してもらう: 落ち着いた在宅オフィスのデスク、読み取れる画面はなし。

kirat_image 評議会に依頼

審査員は gpt-image-2 の画像を選びました (18/20点)。両メンバーが両方の画像を匿名で評価しました。

舞台裏

kirat_image ClaudeがKiratに送る内容

記録日 2026-10-13 · KIRAT_IMAGE · モード: VARIANTS · 横長 · ≈ $0.17

依頼内容: フリーランサー向け小規模請求ツールのランディングページ用ヒーロー画像: 朝の整頓された在宅オフィスのデスクに、ノートパソコン(画面は背を向けるかぼかし、読み取れるインターフェースなし)、コーヒーカップ、紙のノート。自然光、落ち着いたドキュメンタリー風写真スタイル、テキストなし、ロゴなし、人物の顔なし。

評価基準: 実際のフリーランサーの仕事場のように感じられること、ストックフォトのオフィスではないこと · 落ち着いており、散らかっていないこと · 見出し用の余白が確保されていること · テキスト、ロゴ、読み取れる画面がないこと

評議会の結果

Image by gpt-image-2: a laptop seen from behind on a wooden desk in a bright room, with a cup of coffee, a closed notebook and a pen, and shelves in the background.

1 gpt-image-2 · 18/20点 (9 + 9)

Image by gemini-3.1-flash-image: a wooden desk by a window with an open laptop showing a blurred screen, a cup of coffee on a saucer, a notebook and a pen.

2 gemini-3.1-flash-image · 13/20点 (6 + 7)

家具店の商品写真をKiratに作成してもらう: 実際のリビングルームにあるオーク材のダイニングテーブルと椅子4脚。

kirat_image 評議会に依頼

審査員は gemini-3.1-flash-image の画像を選びました (18/20点)。両メンバーが両方の画像を匿名で評価しました。

舞台裏

kirat_image ClaudeがKiratに送る内容

記録日 2026-10-13 · KIRAT_IMAGE · モード: VARIANTS · 横長 · ≈ $0.17

依頼内容: 家具オンラインショップ用の商品写真: 明るく実際のような中央ヨーロッパのリビングルームにある、無垢のオーク材ダイニングテーブルと椅子4脚。自然光、エディトリアルなインテリアスタイル、テキストなし、ロゴなし、人物なし。

評価基準: テーブルが明確な被写体であること · 木目と色が忠実であること · 3Dレンダリングではなく実際の家のように見えること · テキストやロゴがないこと

評議会の結果

Image by gemini-3.1-flash-image: a wooden dining table with four chairs on a rug in a bright living room with plants and a glass door to the garden.

1 gemini-3.1-flash-image · 18/20点 (9 + 9)

Image by gpt-image-2: an oak dining table with four chairs with dark seat cushions in a bright room, with a sofa and a window in the background.

2 gpt-image-2 · 17/20点 (8 + 9)

ケーキ注文ページ用のヒーロー画像をKiratに作成してもらう: 受け取り準備のできた箱入りのバースデーケーキ。

kirat_image 評議会に依頼

審査員は gpt-image-2 の画像を選びました (17/20点)。両メンバーが両方の画像を匿名で評価しました。

舞台裏

kirat_image ClaudeがKiratに送る内容

記録日 2026-10-13 · KIRAT_IMAGE · モード: VARIANTS · 横長 · $0.17

依頼内容: 地元の小さなベーカリーの特注ケーキ新規オンライン注文ページ用ヒーロー画像: 明るく実際のような家族経営のベーカリーの木製カウンターに置かれた完成したバースデーケーキ、シンプルな段ボールのケーキ箱に入って受け取り準備ができている。自然光、ドキュメンタリー写真スタイル、テキストなし、ロゴなし、人物の顔なし。

評価基準: チェーン店やストック写真ではなく、実際の地元のベーカリーのように見えること · ケーキが明確な被写体であること · 見出し用の余白が確保されていること · 画像内にテキストやロゴがないこと

評議会の結果

Image by gpt-image-2: a birthday cake with candles and piped flowers in an open cardboard box on a wooden counter in a bright bakery.

1 gpt-image-2 · 17/20点 (8 + 9)

Image by gemini-3.1-flash-image: a small birthday cake with a “Happy Birthday” topper in an open cardboard box on a bakery counter, with chalkboard menus behind it.

2 gemini-3.1-flash-image · 7/20点 (4 + 3)

請求機能をモノリスから切り離すことに関するブログ記事のカバー画像をKiratに作成してもらう。抽象的で落ち着いたものに。

kirat_image 評議会に依頼

審査員は gpt-image-2 の画像を選びました (16/20点)。両メンバーが両方の画像を匿名で評価しました。

舞台裏

kirat_image ClaudeがKiratに送る内容

記録日 2026-10-13 · KIRAT_IMAGE · モード: VARIANTS · 横長 · ≈ $0.17

依頼内容: モノリスから請求モジュールを切り離すことに関する社内エンジニアリングブログ記事のカバー画像: 密に絡み合ったブロックの集まりから明確に区切られた1つのブロックが分離している、抽象的で落ち着いたイラスト。フラットなスタイル、落ち着いた色合い、テキストなし、ロゴなし。

評価基準: 明確な境界のアイデアが一目で読み取れること · 落ち着いており、劇的でないこと · 小さなサイズでも機能すること · テキストやロゴがないこと

評議会の結果

Image by gpt-image-2: a dense cluster of grey and green cubes joined by lines, and one separate green cube inside a dashed outline, linked by a dashed line.

1 gpt-image-2 · 16/20点 (9 + 7)

Image by gemini-3.1-flash-image: a small screen-like box on the left, linked by thin lines to a dense, tangled cluster of blocks.

2 gemini-3.1-flash-image · 10/20点 (6 + 4)

AI支援スクリーニングに関するカンファレンス講演のカバー画像をKiratに作成してもらう。真面目に、ロボットなしで。

kirat_image 評議会に依頼

審査員は gpt-image-2 の画像を選びました (18/20点)。両メンバーが両方の画像を匿名で評価しました。

舞台裏

kirat_image ClaudeがKiratに送る内容

記録日 2026-10-13 · KIRAT_IMAGE · モード: VARIANTS · 横長 · ≈ $0.17

依頼内容: 系統的レビューにおけるAI支援スクリーニングに関するカンファレンス講演のカバー画像: 机の上に整然と積まれた印刷された研究抄録、いくつかは2つのトレイに仕分けされている、柔らかい日光、ドキュメンタリー写真スタイル。読み取れるテキストなし、ロゴなし、人物の顔なし。

評価基準: 真面目で科学的であり、誇張がないこと · ロボットや光る脳がないこと · 仕分けのアイデアが見えること · 読み取れるテキストやロゴがないこと

評議会の結果

Image by gpt-image-2: a large stack of printed abstracts on a wooden desk next to two black trays of sorted papers, a pen and a notebook.

1 gpt-image-2 · 18/20点 (9 + 9)

Image by gemini-3.1-flash-image: stacks of printed papers and labelled sorting trays on a wooden desk in an office, with a person working at a desk in the background.

2 gemini-3.1-flash-image · 9/20点 (5 + 4)

AI生成画像は縮小され、それ以外は未編集。≈ と記されたコストは並行して実行されたランからのもの: 各ラン自身の画像コストに、評価呼び出しの均等割りを加えたもの。ランキングは事前選択であり、最終的な選択はあなたに委ねられる。ドイツ語で書かれた評価はここで翻訳されている。

02 — 問題

1つのモデルに、1つの盲点。

自己レビューは自分に甘い

モデルが自分の成果物をチェックすると、説得力があると感じてしまう。同じモデルによる2回目のパスは、独立したチェックにはならない。

ラウンドを増やしても解決しない

Kiratは議論をコード上で2ラウンドに制限しており、プロンプトによるものではない。モデルはその制限を言葉で回避することはできない。それでも過半数に達しない場合は、その旨が伝えられる。

異なるファミリーは異なる失敗をする

KiratはClaude、ChatGPT、Geminiに同じ質問を投げかけ、その分かれ方(誰が反対し、その理由を含む)を表示する。

03 — 仕組み

一度尋ねる。3つの立場と投票を得る。

ステップ1

Claudeで尋ねる

いつも通り平易な言葉で: Kirat評議会に尋ねる: 私のショップにはShopifyとWooCommerceのどちらがいい? あなた自身の立場も伝えてください。Claudeが代わりにKiratを呼び出します。

ステップ2

3つの独立した立場

ChatGPTとGeminiは互いの回答を見ずにそれぞれ回答する。Claudeは3人目のメンバーとして自身の立場を取る。

ステップ3

反対意見を残したまま投票

3人のうち2人が同意すれば、それが多数派の見解となる。各立場とその理由、そして誰が反対したかがすべて表示される。過半数に達しない場合、Kiratはその旨を伝え、最終判断はあなたに委ねられる。

Kiratはコードレビュー(各指摘はもう一方のモデルファミリーによってチェックされる)、アイデアのランキング、コピーの批評、画像の比較も行う。上記の再生はそのすべてを示している。

コーディングは不要。Claude拡張機能をインストールし、OpenAIとGoogleでそれぞれ1つのAPIキーを作成するだけ。インストール手順は以下の詳細に記載されている。

9つのツールと記録済みの呼び出し例 →

04 — 料金

Claude DesktopとClaude Code向けの1回の購入。

サブスクリプションなし、シート数なし、当社とのアカウントなし。購入前にKiratの動作環境を確認してください:

Kiratの動作環境

動作する環境

  • macOSおよびWindows上のClaude Desktopチャット
  • ターミナル、VS Code、またはClaude DesktopのCodeタブでのClaude Code
  • クラウド環境ごとに一度のセットアップ後のClaude Codeクラウドセッション 制限付き: ネットワークシークレットとして保存されたキーは読み取り不可のまま(TeamおよびEnterpriseプランでは、管理者が追加する必要がある場合がある)、環境変数内のキーはその環境を使用する全員が読み取り可能、日次予算はセッションごとにカウントされる。

動作しない環境

  • ブラウザでのチャット(claude.ai)またはClaudeモバイルアプリ
  • クラウドで実行されるCoworkタスク
  • 一部の企業環境: Windowsアカウントでサインインするプロキシ(NTLM/Kerberos)、およびDesktop拡張機能を許可リストに制限している組織 最初にITチームに確認してください。

動作環境の詳細 · すべてのクラウド制限

Desktop拡張機能 + Claude Codeプラグイン

Kirat

$99

$99 ローンチ価格 — 先着50名

その後$149。 買い切り。 両形式を含む1つのZIPダウンロード。OpenAIとGeminiのAPIキーも必要: 送信した内容は両プロバイダーに送信され、使用量に応じて両社から請求される。

  • 01Claude Desktop拡張機能とClaude Codeプラグイン、1つのダウンロードに同梱
  • 02Claude Codeクラウドセッション用セットアップスクリプト
  • 03全9ツール: 投票、コードレビュー、アイデアランキング、コピー批評、画像比較など
  • 04コスト管理: 超過する可能性のある呼び出しを抑える日次予算(デフォルト$5)。ベストエフォートのため、プロバイダー側でも制限を設定すること
  • 051人分のライセンス、自分のデバイスとクラウド環境向け
  • 06可能な場合の互換性アップデート — 無料、ただし保証なし Claude Desktop（macOS/Windows）とClaude Codeで動作します。Claude Codeのクラウドセッションでは一度だけセットアップが必要です。ブラウザやモバイルのチャットでは動作しません。動作環境・クラウドの制限

Blueprint

$49

ドキュメントのみ — コーディングエージェントを使って独自のカウンシルサーバーを構築・改変するためのものです。Kiratを使うために必要ではありません。

  • 01仕様書：ツールの構造化された要件
  • 02アーキテクチャの決定事項と、それぞれの背後にある理由
  • 03エージェントが自分で検証できる受け入れチェックリスト
  • 04このサイトの数値の背後にあるベンチマークデータ

コードは含まれず、インストール可能な拡張機能もありません。

一回限りの購入・支払いはLemon Squeezy（記録販売者）経由、VATはチェックアウト時に処理されます・返金については利用規約を参照してください。

API利用料金は、お客様のアカウントを通じてOpenAIとGoogleに直接支払われます。当社の測定では、カウンシルの判断1回につき$0.02〜$0.15です。

こんな方にはKiratは向いていません…

  • —ブラウザやスマートフォンでClaudeをチャットとしてのみ使用している方。KiratはClaude Desktop（macOS/Windows）とClaude Code、および一度だけセットアップすればClaude Codeのクラウドセッションで動作します。これらのチャットでは動作しません。
  • —ホスティングサービスや何らかのサポートが必要な方。
  • —2つのプロバイダーでAPIアカウントと請求設定をしたくない方。
  • —月に数回しか判断を下さず、別々のチャットで手動で回答を比較して満足している方。
  • —確実に聞こえる回答を求める方。カウンシルの仕事は分かれ目を示すことであり、時にはその分かれ目自体が答えです。
  • —データをOpenAIやGoogleに送信できない方。Kiratに与えたすべてのものは、お客様のアカウントとその利用規約の下で、両方に送信されます。

05 — よくある質問

購入前に。

これはllm-councilやPAL MCPとどう違うのですか？

まず両方を見てください。llm-councilはオープンソースのウェブアプリで、作者は設計上サポート対象外と説明しています。PAL MCPはターミナルからインストールする無料のオープンソースMCPサーバーで、多くのプロバイダーをサポートし、独自のコンセンサスツールを備えています。それぞれの現状を確認してください。どちらかが必要な機能をカバーしているなら、それを使ってください。

Kiratの違いはパッケージ全体にあります。Claude Desktop独自の拡張機能ダイアログからインストールでき、キーはオペレーティングシステムのセキュアストレージに保存されます。また、毎日の上限付き予算ガード、2ラウンドの上限、ドメインによるタイブレーク、バックグラウンドチケット、障害処理、345件のテスト、英語の結果フィールド、平易な言葉での使用を備えています。

完全な回答 →

開発者である必要がありますか？

いいえ。Claude拡張機能をインストールして2つのAPIキーを作成できれば、Kiratを使用できます。平易な言葉でClaudeに質問します — Kiratカウンシルに聞いて：PostgresかSQLiteか？あなた自身の立場も伝えてください。 — するとClaudeがツールを呼び出します。

何が必要ですか？

Claude Desktop（macOSまたはWindows）。独自のNodeが同梱されているため、他にインストールするものはありません。またはClaude Code（Node.js 20以降）。Claude Codeのクラウドセッションでは、クラウド環境の一度だけのセットアップが必要です（下記参照）。

さらに、請求が有効なOpenAI APIキーとGoogle Gemini APIキーがそれぞれ1つずつ必要です。Kiratはキー1つでも動作します。その場合、カウンシルには外部メンバーが1人だけとなり、すべての結果に不足しているキーが明記されます。

実行コストはいくらですか？また、請求額が際限なく膨らむのを防ぐものはありますか？

使用量に応じてOpenAIとGoogleに直接支払います。当社の測定では、カウンシルの判断1回のコストは$0.02–$0.15で、労力レベルと入力サイズに応じて8秒から3分かかります。画像生成は1回の呼び出しにつき約$0.05–$0.20です。

予算ガードは、毎回の呼び出しの前に最悪ケースのコストを確保し、毎日の予算を超える可能性のある呼び出しをブロックします。デフォルトはUTC日あたり$5で、調整可能です。これはベストエフォート型なので、プロバイダー側でも支出制限を設定してください。kirat_statusは予算と支出を表示し、コストはかかりません。

完全な回答 →

データとキーはどこに送信されますか？

データ： Kiratに与えたすべてのもの（質問、コンテキスト、コード、画像）は、お客様のアカウントとその利用規約の下で、OpenAIとGoogleに直接送信されます。お客様のコンピューターから、またはClaude Codeのクラウドセッションでは、お客様自身のクラウド環境からAnthropicのネットワークプロキシを通じて送信されます。Kiratサーバーは存在せず、当社のアカウントもテレメトリもありません。当社がお客様のキーやデータを見ることは決してありません。

キー： Claude独自のインストールまたは設定ダイアログで入力します。Claude Desktopはオペレーティングシステムのセキュアストレージ（macOSキーチェーン、Windows資格情報マネージャー）に保存します。Claude CodeはmacOSキーチェーンに保存します。WindowsとLinuxでは~/.claude/.credentials.jsonに保存され、お客様のユーザーのみが読み取れます。支出制限付きの別のプロバイダープロジェクトを推奨します。

Claude Codeのクラウドセッション： Kiratはお客様のクラウド環境で動作します。キーはネットワークシークレットとしてそこに保存します。Anthropicのプロキシが送信時にKiratのリクエストにキーを追加するため、セッション内の誰もキーを読めません。Claudeでさえもです。TeamおよびEnterpriseプランでは、役割によっては組織の管理者がキーを追加する必要がある場合があります。フォールバックとして、キーをその環境の環境変数にすることもできます。その場合、その環境を使用する全員が読み取れます。

お使いのコンピューター上： Kiratはホームフォルダーにフォルダー.kiratを保持し、毎日のコストカウンター、コストログ、直近20件の結果（質問と回答が含まれます）、委任された判断と生成された画像のログを保存します。いつでも削除できます。コンピューター上のすべてのKiratセッション（DesktopとCode）がこれを共有します。

完全な回答 →

KiratはClaude Codeのクラウドセッションでどのように動作しますか？また制限は何ですか？

クラウドセッション — Codeタブのクラウドセッション、ウェブまたはモバイルアプリのClaude Code — は、Anthropicのサーバー上のクラウド環境で実行されます。お使いのコンピューターの拡張機能はそこに到達できません。代わりに、クラウド環境を一度だけセットアップします：

  • ダウンロードのブロック（cloud/setup-script.txt）を環境のセットアップスクリプトの先頭に貼り付けます。
  • 2つのキーを追加します — api.openai.comとgenerativelanguage.googleapis.comのネットワークシークレットとして（TeamおよびEnterpriseプランでは、管理者が追加する必要がある場合があります。ダウンロードのガイドに詳細があります）。それ以外の場合は環境変数として、理想的にはKIRAT_OPENAI_API_KEYとKIRAT_GEMINI_API_KEYという名前で。これらはプロジェクト独自のOPENAI_API_KEYと衝突しません（KiratはOPENAI_API_KEYとGEMINI_API_KEYも受け入れます）。
  • ネットワークアクセス：Fullの場合は変更する必要はありません。それ以外の場合は、パッケージマネージャーのデフォルトリストに加えてKiratのダウンロードホストを許可するCustom（新しいアプリではLimited）に設定します（キーが環境変数の場合は、api.openai.comも許可します）。

スクリプトはお客様のバージョンのKiratを正確にダウンロードし、SHA-256チェックサムを検証してインストールします。これは一度だけのセットアップであり、ワンクリックではありません。当社はクラウドコンテナでテスト済みです。

制限： 環境変数のキーは、その環境を使用する全員が読み取れます（ネットワークシークレットは読み取り不可に保ちます）。すべてのクラウドセッションは新しく開始されるため、Kiratの毎日の予算はセッションごとにカウントされます。OpenAIとGoogleで支出制限を設定してください。クラウドではそれが実際の上限となります。バックグラウンドジョブと最近の結果はセッションとともに終了します。環境のネットワークアクセスはKiratのダウンロードホストを許可する必要があり、キーが環境変数の場合はapi.openai.comも許可する必要があります（Geminiはデフォルトリストに含まれています）。セットアップが失敗した場合でも、セッションはKiratなしで開始されます。そして失敗した状態は、セットアップスクリプトを編集するまで新しいセッションでキャッシュされたままになる可能性があります（変更を加えると、新しいセッションで再実行されます）。

セットアップスクリプトのダウンロードアドレスはZIPと同様に購入品の一部です。公開しないでください。ライセンスはお客様自身のクラウド環境を対象としています。他の人と共有するクラウド環境では、各人にライセンスが必要です。

完全な回答 →

どのモデルを使用しますか？プロバイダーがモデルを廃止した場合はどうなりますか？

デフォルトでは、OpenAIのgpt-5.6とGoogleのgemini-3.6-flashを使用し、Claudeが3番目の投票者として参加します。

モデル名と価格は設定項目です。プロバイダーがモデルを廃止した場合は、新しい名前とその2つの価格を入力してください。アップデートは不要です。

Claude Desktopが「この拡張機能はAnthropicによって検証されていません」と表示します。問題ですか？

その警告は想定内です。Claude Desktopはファイルからインストールされた拡張機能にこれを表示します。Kiratはファイルからインストールされるため、Anthropicによる検証や署名はされていません。

アップデートはどのように行われますか？

Claude Desktopでは、最初と同じ方法で新しい.mcpbをインストールします。キーと設定は保持されます。

互換性アップデートは可能な場合は無料ですが、保証はありません。大規模な新バージョンは別途販売される場合があります。

サポートは受けられますか？

いいえ。Kiratにはサポート、インストール支援、コンサルティングは含まれません。支払いと領収書はLemon Squeezyが処理します。サポートされている環境でKiratが動作しない場合は返金されます。利用規約を参照してください。

ライセンスでは何が許可されていますか？

1人で、お客様自身の任意の数のデバイスとお客様自身のクラウド環境で使用できます。他の人と共有するクラウド環境では、各人にライセンスが必要です。転売や再配布はできません。Kiratはプロプライエタリソフトウェアであり、オープンソースではありません。

カウンシルが生成したものをお客様自身の作業（商用作業を含む）で使用することは問題ありません。完全な条件は利用規約にあります。

Blueprintは何のためですか？必要ですか？

Kiratを使用するために必要ではありません。Blueprintは、コーディングエージェントを使って独自のカウンシルサーバーを構築・改変したい人のためのものです。

ドキュメントのみです — コードは含まれず、インストール可能な拡張機能もありません：仕様書（ツールの構造化された要件）、それぞれの背後にある理由を含むアーキテクチャの決定事項、エージェントが自分で検証できる受け入れチェックリスト、そしてこのサイトの数値の背後にあるベンチマークデータ。バンドル価格はありません。

06 — 詳細

詳細を記録として。

Kiratが動作するすべての場所でのインストール、クラウドの制限、9つのツール、そして数値の背後にある証拠。必要なものを開いてください。

KiratをインストールしてAPIキーを接続する

Kiratはサインアップするサービスではありません。お客様のコンピューター（またはお客様自身のClaude Codeクラウド環境）で、Claude内で、お客様自身のAPIキーを使って動作します。Kiratサーバーは存在せず、当社のアカウントもありません。Kiratに与えたすべてのものは、お客様のアカウントの下でOpenAIとGoogleに直接送信されます。お客様のコンピューターから、またはClaude Codeのクラウドセッションでは、お客様自身のクラウド環境からAnthropicのネットワークプロキシを通じて送信されます。当社がお客様のキーや質問を見ることは決してありません。

Kiratを購入したばかりですか？ ステップバイステップのセットアップガイドに従ってください。最初に使用しているClaudeを選択し、その手順だけを実行します。

ステップ1・時間がかかる部分

2つのAPIキー

請求が有効なOpenAI APIキーとGoogle Gemini APIキーがそれぞれ1つずつ。ここで時間がかかるのは、プロバイダーのサインアップと請求フォームです。支出制限付きの別のプロバイダープロジェクトをお勧めします。

最小権限（任意）：OpenAIでは、制限付きキーで十分です。「モデル一覧」を読み取り、「モデル機能」をリクエストに設定し、それ以外はすべて「なし」にします。Google AI StudioのGeminiキーはすでにGemini APIに制限されています。Google CloudコンソールのキーはGenerative Language APIに制限してください。

両方のキーをすでにお持ちですか？ステップ2に進んでください。

ステップ2

インストール

Claude Desktop： ダウンロードを解凍します。設定 → 拡張機能 → 詳細設定 → 拡張機能をインストール…を開き、.mcpbファイルを選択します。ダイアログで両方のキーを入力します。Desktopには独自のNodeが同梱されているため、他にインストールするものはありません。

Claude Code： ダウンロードを解凍し、展開されたkiratフォルダーをホームフォルダーに移動して、~/kirat/claude-codeが存在するようにします。次に以下のコマンドを実行します。Node.js 20以降が必要です。

Claude Codeのクラウドセッション： 制限付きのクラウド環境の一度だけのセットアップ — 下記参照。

ステップ3

質問する

インストールを確認：Kirat拡張機能を使用してkirat_statusを呼び出します。両方のAPIキーをOpenAIとGoogleで無料でチェックします。

次に実際の質問をします：Kiratカウンシルに聞いて：PostgresかSQLiteか？あなた自身の立場も伝えてください。 またはテンプレートから始めることもできます。Claude Desktopではメッセージボックスの**+**ボタンから、Claude Codeではプラグインとして/kirat:decide、/kirat:review、/kirat:critique、または/kirat:brainstormから始められます。Claude Codeのクラウドセッションでは、これらは/mcp__kirat__decide、/mcp__kirat__review、/mcp__kirat__critique、/mcp__kirat__brainstormと呼ばれます。

# in Claude Code, once ~/kirat/claude-code exists
/plugin marketplace add ~/kirat/claude-code
/plugin install kirat@kirat
# enter both keys when asked; to change them later:
/plugin configure kirat@kirat

Claude Desktopは、この拡張機能がAnthropicによって検証されていないことを警告します。この警告は、ファイルからインストールされたすべての拡張機能で想定されるものです — FAQを参照。

実行される場所、全体像、クラウド制限 9つのツールと記録された呼び出し例

あなたが平易な言葉で質問します。Claudeが呼び出しを行います：

// a real call and a real answer — nothing staged
kirat_vote({
  question: "Cap the coupled effort default, or leave it at maximum?",
  options: ["cap at high", "decouple", "leave as is"],
  ownPosition: { position: "cap at high", reasoning: "…", confidence: 72 }
})
→ outcome:       "completed"
  decision:      "cap at high"
  decisionPath:  "unanimous"
  rounds:        1
  votes:         openai 94, gemini 92,
                 claude 72
  cost:          $0.021

その他の結果：needs_human（過半数なし — あなたが決定）、domain_decision、limited、budget_exhausted。信頼度の値は各モデル自身の自己申告です。

図6.3 — 部品リスト

Claudeが呼び出す9つのツール

APIコストあり7つ · なし2つ

順位ツール機能APIコスト
01kirat_vote投票による決定：各メンバーが立場を取り、その後3分の2以上の多数決、ドメイン所有者、またはneeds_human。APIコスト
02kirat_reviewコードレビュー。すべての指摘はもう一方のモデルファミリーによって検証されます。APIコスト
03kirat_createあなたの下書きを批評、メンバーに下書きを依頼、または短いバリエーションをランク付け。APIコスト
04kirat_brainstorm3つのトラックでの発散的アイデア — 指示内、隣接、ルール破り — 匿名でランク付け。APIコスト
05kirat_decide可逆的な作業選択のための委任決定。拒否権と1日の制限付き。APIコスト
06kirat_askちょうど1人のメンバーに質問。評議会なし。APIコスト
07kirat_image両プロバイダーによる画像生成。匿名の審査員によって評価されます。APIコスト
08kirat_resultバックグラウンドジョブと最近の結果を取得。なし
09kirat_status予算、支出、利用可能なメンバー、設定、無料キーの確認。なし

「APIコスト」とは、ツールがあなた自身のキーでOpenAIとGoogleを呼び出し、それらのプロバイダーに直接支払うことを意味します。上記のリプレイは各実行のコストを示しています。Kirat自体は使用ごとに課金されません：一度購入するだけです。kirat_imageと画像入力はコンピューター上のファイルで動作するため、Claude Codeに最も適しています。

証拠：記録された決定、測定されたコスト、文書化された失敗