「お店で定期便を始めたい。毎月届けて、1割引きにしよう」。こんな思いつきをAIに話したら「いいですね、進めましょう」と返ってきて、そのまま準備を始めてしまったことはありませんか。
grill-meは、AIに計画を問い詰めてもらうSkillです。今答えられる論点を番号と推奨案付きでまとめ、回答を受けて次の論点へ進むよう指示しています。編集部が架空のコーヒー豆の定期便を試すと、最初に7問、回答したあとに5問が出ました。
今回、計画書などのファイルは作られませんでした。会話に残ったのは、問い詰められて気づいた「決めていなかったこと」と、その答えです。
この記事では、2026年10月10日に、ユーザー単位の設定・プラグインとMCP（外部ツールへの接続）を除外した新しいClaude Codeの会話で試した結果を紹介します。頼み方、答え方、注意点を見たあと、後半では、この動きを支えるSkillの指示の書き方を読み解きます。
こんなふうに、計画を問い詰めてもらえる
依頼は、思いついたままの言葉で構いません。
/grill-me 自分のオンラインショップで、コーヒー豆の定期便を始めたい。 毎月決まった日に200gを届け、通常価格より1割安くするつもり。 この計画を厳しく問い詰めてほしい。
実際には7問が届きました。見出しは、定期便の目的、1割引でも赤字にならないか、配送方法、決まった日の意味、届ける豆の選び方、豆か粉か、継続課金の仕組みです。そのうち3問を、推奨案と一緒に抜粋します。
❓ Q1 - 定期便の目的: 定期便で何を一番得たいですか？
- (a) 毎月の売上を安定させ、焙煎量を予測しやすくしたい
- (b) 新規客を増やしたい（入口商品として使う）
- (c) 既存客の客単価や購入頻度を上げたい
目的によって「1割引」が妥当かどうかが変わります。(a)なら割引は「継続してくれることへの対価」です。(b)なら初回だけ大きく割り引くほうが効きます。(c)なら割引より限定豆などの特典のほうが効く場合があります。
➡️ 目的は(a)の売上安定と焙煎計画の予測です。小さな店の定期便が一番価値を出すのはここで、ほかの判断の基準もここに置きます。
❓ Q4 - 「毎月決まった日」の意味: 決めるのは「発送日」で、「到着日」は約束しない、ということで良いですか？ ポスト投函型では到着日を保証できません。また、コーヒー豆は鮮度が売りです。「毎月◯日に焙煎し、翌日に発送」と焙煎日を軸にすると、作業も一括でまとめられて、お客さんへの訴求にもなります。
➡️ 毎月の焙煎日・発送日を固定します（例：毎月10日焙煎、11日発送）。到着日は「目安」として伝えるだけにします。
❓ Q6 - 豆か粉か: 届けるのは豆のままだけにしますか？ 挽き売りを入れると、挽き目（ペーパー・フレンチプレスなど）ごとにパターンが増え、毎月の作業が膨らみます。粉は鮮度も落ちやすいです。一方、ミルを持っていない人は申し込めなくなります。
➡️ 最初は豆のままのみで始めます。粉の要望が一定数集まったら、中挽き1種類だけを追加します。
編集部がClaude Code（v2.1.296、Opus 5.5）で実行したときの応答の抜粋（2026年10月10日、権限モードacceptEdits）。架空のお店の設定を使用。Skillは試験開始前の保存コミットdf95616の版です。
❓が質問、➡️がAIの推奨案です。今回の質問は、番号と見出しを別々に太字にする形まで、原文の手本に沿っていました。全問が互いに独立だったかまでは検証していません。
続いて、全7問へ番号ごとに答えました。長い回答なので、ここでは実際に送った内容の要約を示します。
- 主な目的は売上の安定。個人経営で、まず2回以上買ったお客様を対象にし、毎月買う常連は約40人。
- 200gは通常1,800円、豆の原価約600円、送料は全国一律の店負担で約400円、梱包材約80円。決済手数料は分からない。
- 配送方法、焙煎日・発送日の固定、豆の選び方、豆のまま届ける案は「推奨どおり」。焙煎は店主1人で1日最大15kg。
- 販売は自分のネットショップ1つ。サービス名は答えず、自動課金や定期注文の管理機能、アプリ費用も「分からない」。解約しにくい仕組みにはしたくない。
この回答のあと、2ラウンド目は5問になりました。採算、課金機能、解約条件、会員上限、対象者の絞り方に進んでいます。回答した数字や方針が、次の質問にどう入ったかを2問で見ます。
❓ Q1 - 常連に割引することによる利益減: いま毎月買っている常連約40人が定期便に移ると、売上は増えずに割引分だけ減ります（送料400円のままなら月に約7,000円の減少）。それでも「1割引」を続けますか？ 決める条件は、ポスト投函で実際に送料が約200円になることです。
- (a) 送料を約200円にできた場合だけ1割引にし、できなければ5%引きにする
- (b) 送料に関係なく1割引にする
- (c) 割引はせず、焙煎日の発送や限定豆などの特典だけにする
➡️ (a)です。1割引にする前に、ポスト投函の実際の送料を確認します。送料の差額で割引分をまかなえない場合は5%引きにします。
❓ Q3 - 解約・スキップの条件: 「解約しにくくしない」という方針なら、次の条件で良いですか？
- 最低継続回数なし。初回のあとすぐに解約できる
- 解約・スキップ・住所変更の締切は「焙煎日の5日前」まで
- 受付はマイページから（ない場合はメール1通で済ませる）
- 締切を過ぎたら、その月分は発送して翌月から反映する
締切がないと、焙煎量を決めた後に解約が入り、豆が余ります。
➡️ 上の4条件にします。締切は焙煎日の5日前とします。
編集部がClaude Code（v2.1.296、Opus 5.5）で実行したときの応答の抜粋（2026年10月10日、権限モードacceptEdits）。架空のお店の設定を使用。Skillは試験開始前の保存コミットdf95616の版です。
「毎月買う常連40人」という回答は割引による利益減の話へ、「解約しにくくしたくない」は具体的な締切や受付方法の話へつながりました。解約・スキップの条件は2ラウンド目に出ましたが、値引きの代わりの特典は、1ラウンド目の目的を聞く説明にも触れられていました。「特典は2ラウンド目に回る」とラウンドを固定した以前の記事の説明とは違います。
AIは会話の数値から採算表も作り、決済手数料は一般的な幅として仮置きしていました。表の「利益約390〜480円」は、送料400円と仮の決済手数料を使ったAIの試算です（要約）。店の実際の手数料を調べた数字ではありません。編集部が入力値だけで確かめた単純差額は、1,620−600−400−80＝540円で、ここから手数料や作業費などを引く必要があります。
会話の記録は編集部で保存しています。今回、依頼1〜3以外の補足指示は送っていません。コネクタの呼び出しや権限確認もありませんでした。
便利なのは、まだ固まっていない計画
AIに「厳しく質問して」と頼むこと自体は、Skillがなくてもできます。
grill-meを入れると変わるのは、問い詰め方の決まりを毎回説明しなくてよくなる点です。答えが出ていない質問に依存する論点は後回しにして、今答えられるものだけをまとめて聞くこと。質問には推奨案を付けること。調べれば分かることは利用者に聞かないこと。決めることが残っている限り終わらないこと。そして、利用者が「認識がそろった」と確かめるまで実行に移らないこと。これらがSkillに書かれているので、依頼は計画を伝えるだけで済みます。
公式ドキュメントは、計画がまだ漠然としている段階こそ使いどきだと説明しています。曖昧さを取り除くのがこのSkillの役目だからです。効果が大きいのは、たとえば次のような場面です。
- 新しい施策や事業案を、上司や関係者に出す前に固める
- 提案書や見積もりを出す前に、前提の抜けや想定される反論を洗い出す
- 運用ルールや評価制度の変更を入れる前に、現場で揉めそうな点を先に見つける
一方で、向かない場面もあります。「1ページの長いフォームと3ページに分けるのと、どちらがいいか」のように、実物を見ないと答えられない問いは、いくら話しても決まりません。公式ドキュメントは、そうした問いにぶつかったら問い詰めを止めて、使い捨ての試作を作って見てから戻るよう勧めています。また、すでに細部まで決まっている計画なら、問い詰める必要はありません。
導入して、同じ例を試す
導入の前に知っておくこと
grill-meは入口で、中身はgrillingというSkillにあります。 grill-meのSKILL.mdには「grillingを呼ぶ」という一文しかなく、問い詰め方はすべてgrillingに書かれています。両方を入れておく必要があります。
自動では起動しません。 grill-meは、AIが会話の流れから勝手に使い始めない設定になっています。/grill-meと打って呼び出します。
新しい会話で始めます。 公式ドキュメントは、AIにすでに書かせた計画の上で始めず、新しい会話で始めることを勧めています。Claude Codeでは、入れた直後のSkillが起動中の会話で使えないこともありました（編集部の試行、2026年9月18日）。また、計画を急いで作ろうとする「プランモード」はオフにしておくよう書かれています。
計画の中身は、使っているAIサービスに送られます。 社外秘の計画を問い詰めてもらう場合は、AIサービスの規約と社内ルールに沿って扱ってください。Skill自体は無料のOSSですが、AIサービスの利用料は別にかかります。
インストールする
作業するフォルダで、次のコマンドを実行します。grill-meとgrillingを一度に入れるためのコマンドです。今回は導入済みの版を使い、再インストールはしていません。
npx skills add https://github.com/mattpocock/skills --skill grill-me --skill grilling
今回の起動条件を再現するには、同じフォルダで次のようにClaude Codeを起動します。ユーザー単位の設定・プラグインとMCP接続を除外するためのオプションです。通常の環境に追加プラグインがある場合と結果が違う可能性があります。
claude --setting-sources project,local --strict-mcp-config --permission-mode acceptEdits
導入確認では、AIが2つのSKILL.mdを実際に読めるかを確かめます。次は確認用の依頼例で、この再試験では送っていません。
grill-meとgrillingのSKILL.mdを読み、見つかったファイルの場所と概要を教えてください。 見つからない場合は、その旨を教えてください。
場所と概要が返ってきたら、/grill-meで計画を送り、❓と➡️の形の質問がまとめて届くかを確かめます。AIが「使えます」と答えただけでは、導入できた証拠になりません。Skillの読み込み方はAI環境によって違うため、この確認方法も成功を保証するものではなく、確かめる手がかりです。
依頼して、答える
計画は、思いついたままの言葉で構いません。届いた質問には、番号ごとに答えます。推奨案でよければ「Q1：推奨どおり」で足ります。
大事なのは、受け身にならないことです。公式ドキュメントは、40問に「同意」と答え続けて、AIが書いた計画にうなずいただけで終わる状態を、いちばんの失敗として挙げています。質問の粒度が足りなければ押し返す、範囲がずれてきたら言う、分からなければ「分からない」と答える。答えの質が、結果の質を決めます。
答え終わったあと
原文は、決めることがなくなるまでラウンドを繰り返すよう指示しています。今回も回答後に次の質問へ進みましたが、2ラウンド目には答えず一覧化を頼んだため、全論点を解消した場合の終わり方は試していません。公式ドキュメントでは、4ラウンドで46問というのが普通の長さだと説明されています。質問の数ではなく、ラウンドの数で進み具合を見ます。200問のように膨らんだときは、計画の範囲が大きすぎる合図です。いったん止めて、計画を小さく分けてから、1つずつ問い詰めます。
すべての論点に答え、AIと認識がそろったら、計画を実行に移せます。AIは、利用者が「認識がそろった」と確かめるまで、その計画に基づいた作業を始めないよう指示されています。
自動ではやらないこと
原文には、計画書を保存したり、途中の決定をファイルへ記録したりする指示はありません。今回も、会話記録を回収する前のgit statusに変更はなく、新しい計画ファイルはありませんでした。ファイル書き込みを禁じる補足を送った結果ではありませんが、この1回であらゆる依頼に対してファイルを作らないとは言い切れません。
2ラウンド目には答えず、次を送りました。
ここまでに決めたことと、まだ残っている論点を一覧にしてください。
一覧は会話に出ました。「決まったこと」10項目、「回答待ち」5問、「まだ質問していない論点」7項目に分かれていました。次は決定済みの表の冒頭と、回答待ちの表の最初の項目です。
# 論点 決定内容 1 目的 毎月の売上を安定させ、焙煎量を予測しやすくすること 2 対象者 まずは2回以上購入したことのあるお客様（毎月の常連は約40人） 3 数値の前提 通常価格1,800円／200g、豆原価約600円、送料は全国一律の店負担で約400円、梱包材約80円
# 論点 推奨案 決めるための材料 Q1 常連に割引することによる利益減と割引率 送料を約200円にできれば1割引、できなければ5%引き ポスト投函の実際の送料
編集部がClaude Code（v2.1.296、Opus 5.5）で実行したときの応答の抜粋（2026年10月10日、権限モードacceptEdits）。架空のお店の設定を使用。Skillは試験開始前の保存コミットdf95616の版です。
「推奨どおり」と答えていない2ラウンド目の提案は、決定済みへ混ぜず回答待ちに残していました。推奨案と決めたことを分けて確認できます。一覧を出すことと、計画書へ保存することは別です。
そのため、区切りのよいところで次の手順を自分で回します。
- 「ここまでに決めたことと、まだ残っている論点を一覧にしてください。」と頼む（今回、一覧が出たことを確認しました）
- その一覧を、計画書や課題管理のツールなど、会話の外に保存する
- 残った論点を、次に誰がいつ決めるかを書き添える
- 再開するときは、保存した一覧を新しい会話に渡して続きを頼む
使う前・決める前に見るのは3点
1. 推奨案に「はい」と言い続けていないか。 今回の5%引き、月額費用5,000円超という目安、締切5日前、会員上限30人には、統計や出典の提示がありませんでした。決済手数料や送料約200円も仮の前提です。編集部は表に置かれた数値の差し引きを確認しましたが、料金の実態や推奨値の妥当性は裏取りしていません。作業時間、光熱費、アプリ費用なども採算表に入っていないので、利益確定の根拠には使わず、実際の費用で計算し直してください。
2. 不明な事実が、推奨案で埋められていないか。 今回、15kgが生豆か焼き上がりかは設定にありませんでした。それでも2ラウンド目の推奨は「15kgは生豆の量とし」と置いて会員上限30人を提案しています。最後の一覧では、15kgの意味を「決めるための材料」に戻していました。実際の能力は推奨で決める事柄ではありません。原文は環境から調べられる事実をAIに調べさせますが、今回の自動課金機能はサービス名を答えなかったため利用者へ確認を頼んでいました。配送の制約、焙煎の目減り、法制度、顧客反応の主張も今回裏取りしていません。実際の運用へ使う前に、一次資料や店の記録で確かめてください。
3. 範囲が大きすぎないか。 質問がいつまでも終わらないときは、計画を分けるサインです。公式ドキュメントは、長すぎる会話ではAIの文脈がいっぱいになり、質問の質が落ちることにも触れています。
このSkillは、AIへの仕事の教え方をどう組み立てているか
ここからは、自分でSkillを書く人に向けた内容です。
前半では、定期便の計画を問い詰めてもらう流れを見ました。後半では、その動きを支えているSKILL.mdの書き方を読み解きます。
grillingの本文は、短い段落が5つほどしかありません。それでも、「どう呼ばれるか」「何を先に聞くか」「どんな形で聞くか」「誰が何をするか」「いつ終わるか」が書き分けられています。それぞれを、同じ定期便の例に当てはめて見ていきます。
全体の構造
関係するファイルは次のとおりです。
grill-me/SKILL.md … 入口。「grillingを呼ぶ」の一文だけ。自動起動しない grill-me/agents/openai.yaml … 他のAIツール向けの表示名と、自動起動しない設定 grilling/SKILL.md … 本体。問い詰め方のすべて （今回の試行） … 計画ファイルは生成されず、質問・回答・一覧は会話に残った
grillingの流れを一行にすると、次のとおりです。
計画を「決めることの木」として捉える → 前提がそろった質問をすべて1ラウンドにまとめる → 番号と推奨案を付けて聞く（事実が必要な質問はAIが調べる）→ 回答を待つ → 答えをもとに次に聞ける質問を計算し直す → 決めることがなくなるまで繰り返す → 利用者が確かめるまで実行しない
原文には、状態をファイルへ保存する手順、ラウンド数の上限、途中経過を記録する仕組みはありません。今回の質問・回答・一覧も会話に出て、証拠の保存は編集部が別に行いました。
以下の5つの解説は、いずれも「原文の書き方 → 定期便の例でどう働くか → 省いたら起こりうること → 自分のSkillへの応用」の順で書きます。「定期便の例でどう働くか」は今回の試行結果を中心にし、試していない挙動は原文の指示と分けて説明します。「省いたら起こりうること」は設計上の推論で、比べて試した結果ではありません。「応用する指示の例」は編集部の提案で、原文の引用ではありません。
1. 呼び出し名と中身を、別のSkillに分ける
原文の書き方（grill-meとgrillingのfrontmatter）
grill-meは、descriptionに「計画や設計を磨くための容赦ない聞き取り」とだけ書き、disable-model-invocation: trueで自動起動を止めています。本文は「grillingを呼ぶ」の一文です。一方のgrillingは、descriptionに「計画、決定、アイデアについて容赦なく問い詰める。利用者が考えを試したいとき、またはgrillを含む言い回しを使ったときに使う」と書き、自動起動を止めていません。
定期便の例でどう働くか
今回、/grill-meで依頼すると、ログにSkillツールがgrillingを読み込んだことが残りました。入口から本体を呼ぶ指示に沿った動きです。他の入口から本体を呼ぶ挙動は今回は試していません。
省いたら起こりうること
呼び出し名ごとに問い詰め方を書き写すと、片方だけ直したときに動きがずれていきます。逆に、中身のSkillしかないと、人が覚えて打つ短い名前を安定して用意しにくくなります。
応用する指示の例
（入口のSkill）disable-model-invocation: true 本文：「review-core」Skillを呼ぶ。
同じ考え方を複数の入口から使わせたいときは、中身を1つのSkillにまとめ、人が呼ぶ入口は一文だけの薄いSkillにします。直すのは中身の1か所だけで済みます。
2. 「今答えられる質問」を定義して、まとめて聞く
原文の書き方（grilling本文の第1・2段落、第4段落）
計画を「設計の木」として捉え、すべての決定がそこからぶら下がる決定へ枝分かれする、と書いています。そのうえで「フロンティア」を、前提となる決定がすでに決まっている質問、つまり、まだ聞いていない答えを推測せずに今聞ける質問の集まりと定義します。1ラウンドではフロンティアをすべて聞き、答えのたびに計算し直します。同じラウンドで聞いている別の質問に答えが依存する質問は、次のラウンドに回します。
定期便の例でどう働くか
今回、特典の可能性は1ラウンド目のQ1で触れられ、2ラウンド目Q1では「割引せず特典だけ」という選択肢が出ました。「特典は最初には入らず次に回る」という以前の記事の説明とは違います。一方、解約・スキップの具体条件は、回答の方針を受けて2ラウンド目Q3に出ています。常連40人という回答も割引の質問に入りました。回答で問いが深まったことは観察しましたが、質問すべての依存関係を検証したわけではありません。
省いたら起こりうること
1問ずつ聞くと、往復の回数が増えます。依存関係を考えずにまとめて聞くと、前の答え次第で意味がなくなる質問に答えさせることになります。
応用する指示の例
質問する前に、どの決定がどの決定を前提にしているかを整理する。 前提がすべて決まっている質問だけを1回にまとめて聞き、残りは回答を受けてから聞く。
確認や聞き取りをするSkillでは、「いくつずつ聞くか」ではなく「どの質問なら今聞けるか」を基準にします。
3. 出力の形を手本で固定し、「はい」で推奨案を受け入れられる問いにする
原文の書き方（grilling本文の書式の例）
1ラウンドの書き方を、❓ **Q1** - **<質問の見出し>**: <質問本文>、続けて➡️ <推奨する答え>、という手本で示しています。さらに「『はい』と答えれば推奨案を受け入れたことになるように、質問を言葉にする」と書いています。
定期便の例でどう働くか
今回の1ラウンド目7問と2ラウンド目5問では、すべてに❓、番号、見出し、➡️の推奨案があり、番号と見出しを別々に太字にする手本にも沿っていました。推奨案でよいものには「推奨どおり」と返しました。ただし、最後の一覧化への応答は質問の形ではなく表でした。質問ラウンドの形式と、別の依頼への応答形式は分けて見ます。
省いたら起こりうること
形が決まっていないと、推奨案が本文に埋もれたり、どれが質問なのか分かりにくくなったりする可能性があります。推奨案と質問の向きがずれていると、「はい」がどちらへの同意なのかが曖昧になります。
応用する指示の例
質問は次の形で出す。 ❓ Q<番号> - <見出し>: <質問> ➡️ <推奨する答え> 「はい」と答えれば推奨する答えを選んだことになるように、質問の文を作る。
人が答える出力は、言葉で説明するより手本を1つ示した方が形がそろいます。答える側の手間まで考えて、質問の向きを決めておきます。
4. 事実はAIが調べ、決めることだけを人に聞く
原文の書き方（grilling本文の第5段落）
「事実を見つけるのはあなた（AI）の仕事で、利用者の仕事ではない」と書き、ファイルやツールなどの環境にある事実が必要な質問では、サブエージェント（別のAI）を調べに出すよう指示しています。調べている間も、それに依存する質問だけを待たせ、ほかの質問は先に聞きます。決めることは利用者のものなので、1つずつ聞いて回答を待つ、と分けています。
定期便の例でどう働くか
今回はショップのデータファイルを置いていないため、ファイル調査やサブエージェントによる調査と質問の並行は試していません。それは原文が指示する動きです。観察したのは、会話の数字から採算表を作り、不明な決済手数料を仮置きしたことです。ショップ機能は「サービス名が分からないので、こちらでは調べられません」と利用者へ確認を頼みました。必要な情報がない条件では、自力で事実を調べた結果とは言えません。
省いたら起こりうること
調べれば分かることまで聞くと、利用者の負担が増え、答えの質も下がります。逆に、決めるべきことまでAIが決めると、利用者は自分の計画を持てなくなります。
応用する指示の例
ファイルや資料を調べれば分かることは、利用者に聞かずに自分で調べる。 調べている間も、その結果を必要としない質問は先に聞く。 方針や優先順位など、利用者が決めることは、推奨案を添えて質問し、回答を待つ。
人に聞くSkillでは、「調べること」と「決めてもらうこと」を書き分けます。前者はAIの仕事、後者は人の仕事として明記します。
5. 終わる条件と、実行に移る条件を分ける
原文の書き方（grilling本文の最終段落）
「フロンティアが空になったら、つまり設計の木のすべての枝を訪れ、黙って前提にしたものが何も残っていないときに終わる」と書いています。続けて「利用者が、認識がそろったと確かめるまで、それに基づいて行動しない」とあります。
定期便の例でどう働くか
今回、回答後に次の5問へ進み、一覧にも回答待ちと未質問の論点が残りました。一覧化を頼むと質問を続ける代わりに整理し、商品ページの作成などには進みませんでした。補足の禁止指示は送っていません。ただし全論点を解消した後の停止・実行は試していません。利用者が認識を確かめるまで動かないことは、原文の指示として説明しています。
省いたら起こりうること
終わる条件がないと、AIはそれらしいところで質問を切り上げる可能性があります。実行に移る条件がないと、問い詰めが終わった勢いで、確認を待たずに作業を始める可能性があります。
一方で、原文にはラウンド数の上限や、あと何ラウンドかかるかの見通しを示す指示はありません。今回も、一覧に7項目の未質問の論点があり、完了まで何ラウンドかかるかは示されませんでした。
応用する指示の例
確認すべき論点が残っている間は終わらない。論点が残ったまま止める場合は、残りを一覧にして渡す。 終わったら、決めたことの一覧を示し、利用者が確かめるまで次の作業を始めない。 各ラウンドの最後に、残っている論点のおおよその数を示す。
残りを一覧にして渡すこと、決定一覧を自動で示すこと、残っている論点のおおよその数を示すことは、grilling原文にない追加案です。今回の一覧は、編集部が別に依頼した結果です。聞き取りを続けるSkillでは、「いつ終わるか」と「いつ動いてよいか」を別々に書き、長くなるときの見通しも伝えるようにします。
各指示の原文は、grilling SKILL.md原文とgrill-me SKILL.md原文で確認できます。
補足：Skillの基本情報
- Skill名：
grill-me（Skills.sh）。中身はgrilling - 作者・リポジトリ：Matt Pocock（mattpocock/skills）
- 料金：Skill自体はOSSで無料。AIサービスの利用料は別途
- 呼び出し方：
/grill-me <問い詰めてほしい計画>。grill-meはAIによる自動起動をしない - 注目度（2026年10月9日確認）：インストール数1.3M、初登場2026年3月13日。GitHub Stars 280.9K（Skills.sh表示。リポジトリ全体の数字）
- セキュリティの自動監査（2026年10月9日確認）：Gen Agent Trust Hub、Socket、SnykはいずれもPass。自動監査の表示で、安全性を保証するものではない
情報源・参考リンク
