sidecrew

sidecrew

ソースコードの変更を依頼すると、Mac 上でモデルが変更を行い、マシンによる検証を通過した後に結果が返ってきます。Claude のトークンは消費しません。

Claude Opus が作業を計画し、返ってきた結果をレビューします。狭い範囲の作業は、ローカルで実行する小規模モデル（MLX、ネットワーク接続なし）が担当します。その間に、マシンで実行できるゲートを設けています。コード変更の場合、差分が指定された範囲内にとどまっていること、tsc がエラーなく完了すること、変更前に成功していたすべてのテストが引き続き成功することを確認します。Claude が見るのは、このゲートを通過したものだけです。

$ sidecrew fix change_plan.json
fix 2026-09-20T09-14-02Z-rename: 1 step, 12 tasks, 13.0 GB free ÷ 6.5 GB per slot = 2; 1 worker up
step 1/1 "rename the helper": capturing the baseline
rename-01: survived (src/util/asset.util.ts)
rename-02: survived (src/util/asset.util.ts, src/util/asset.util.spec.ts)
…
multi-06: failed at compile · escalating — renamed the symbol 7 times over, 5 compile errors
11/12 survived · 0 → 0 tsc errors · .sidecrew/runs/2026-09-20T09-14-02Z-rename/result.json

形を示すための例であり、実際の会話記録ではありません — 以下の React の測定結果の件数を使った実際の出力形式で、クライアントのファイル名は含まれていません。95 % 区間が [0.615, 0.998] の 11/12が数値です。上の行は、実行中の表示例です。

ワークロード #1 はユニットテストです。ミューテーションキルゲートを使った同じ形式で、その数値と区間は以下に記載しています。

sidecrew の実行には、搭載 RAM が 24 GB 必要です。それ未満では、通常の作業負荷と並行して 7B モデルを実行できないことが測定で確認されているため、sidecrew は実行を拒否し、その理由を伝えます。静かに別のツールへと変わってしまうことはありません（ADR-0073）。何かを計画する前に、sidecrew doctor で確認できます。

**もう一つのコストも明らかにしておきます。2026 年 9 月 19〜20 日に測定した結果：**ワーカーは無料ですが、調整にはコストがかかります。Opus による計画では、タスクあたり 8,400〜22,100 トークンを消費します。これはほぼ全面的に、計画に含まれるタスク数で決まります。詳しくは以下の「実行にかかるコスト」をご覧ください。この点を明記せずに「作業は無料」とうたうページは、全体の半分しか伝えていません。

以下の数値を読む前に：どこまで厳密に読み取るべきか

このページに記載されている率はすべて、点推定値ではなく区間です。その理由は測定によって明らかになっています。フロンティアモデル自身の差分をゲートに再度通したところ、ゲートは欠陥を検出しませんでしたが、同じ候補 19 件のうち 2 件で判定が食い違いました。D = 0.105、95 % 区間は [0.013, 0.331] です（最初の再実行前に固定したルールに基づく experiments/gate-error-rate/）。そのルールでは D > 0.10 の判定は許容不可であり、その結果として、この段落の方針を定めています。ここでは生存率を単なる割合として公開せず、各率に D を併記し、差がこれを考慮してもなお残るかを確認せずに、二つの率を比較することはありません。

この測定が損なうもの、損なわないもの。 D が数えるのは、ゲートが問題のなかった変更を拒否したケースです。ゲートが悪い変更を通してしまった証拠にはなりません。したがって：

ゲートは失敗するものを通さない — この主張は維持されます。 ゲートが拒否するのは失敗するものだけ — 測定で誤りと判明しており、およそ 10 回に 1 回は該当します。それ以上の精度での裏付けはありません。

既知の原因 3 つのうち 2 つは、現在、すべての判定に記録されています。メモリ圧迫（ADR-0066）と、異なる暦日に取得されたベースラインです（ADR-0069）。残りの 1 つは未診断で、測定された食い違いはどちらもマシンがアイドル状態のときに発生したため、最初の 2 つの原因には該当しません。D はワークロード #2a のゲートで測定した値です。異なるオラクルを使うワークロード #1 のミューテーションゲートについては、何も示しません（ルールの §4.4）。

ワークロード #2a — 振る舞いを維持する変更の測定結果

ツールが判定を1件も出す前に固定した判定ルールに照らした結果です （experiments/go-no-go-2a/results/REPORT.md）。S は生存、A は差分に対する盲検レビュー担当者の承認を表します。各セルは正確な95 %信頼区間を付した k/n です。D = 0.105 [0.013, 0.331] はすべての S に適用されます。

入力	S、ローカル7B	S、Haikuコントロール	A、ローカル7B	A、コントロール
フィクスチャ	3/3 [0.292, 1.000]	3/3 [0.292, 1.000]	1/3 [0.008, 0.906]	3/3 [0.292, 1.000]
商用のNest/jestコードベース	12/12 [0.735, 1.000]	12/12 [0.735, 1.000]	9/10 [0.555, 0.997]	10/10 [0.692, 1.000]
商用のReact/jestコードベース	11/12 [0.615, 0.998]	12/12 [0.735, 1.000]	9/10 [0.555, 0.997]	10/10 [0.692, 1.000]

分数ではなく信頼区間を見てください。このサンプル数では、12/12 と 11/12 は区別できず、A における7Bとコントロールにも差はありません。実プロジェクトはどちらも、10件のサンプルで、固定済みのルールをちょうど余裕ゼロで通過しました。生存率では何も決まりませんでした。測定可能な6セルのうち5つが0.917以上だったため、ルールの比率条項は機能せず、ローカル7Bとネットワークモデルを分けた唯一の要素は承認率でした。

測定されたこの承認率が示すのは、ローカルモデルが要求されていない見た目上の編集（削除されたドックブロック、言い換えられたコメント、紛れ込んだ空行）を、サンプルに含まれた生存例23件のうち4件 [0.050, 0.388] で行っていることです。一方、コントロールでは23件中0件 [0.000, 0.148] でした。confined ∧ compiles ∧ tests pass ではこれを検出できません。そこが重要なのです。

Opus にただ尋ねるだけの場合と比べて得られること

2026年9月18～19日に、同僚が今日実際に行っている方法、つまり、計画もゲートもなく、1つずつタスクをフロンティアモデルに直接依頼する方法と比較して測定しました。同じ手書きの19タスク、同じ2つのコードベース、4つの実行条件です。

	Opus のみ	Sonnet のみ	sidecrew
トークン数、19タスク、Nest コードベース	80,131	88,820	0
トークン数、19タスク、React コードベース	95,335	88,680	0
Opus との出力比較、Nest コードベース	—	19/19で同一	19件中18件で同一
提出され、検証された変更、Nest	19（未検証）	19（未検証）	19/19が [0.824, 1.000] で成立
提出され、検証された変更、React	19（未検証）	19（未検証）	19件中15件が [0.544, 0.939] で成立、4件をエスカレーション

トークン数の列は実数で、正確な値です。成立率の行は率なので、区間を併記しています。D = 0.105 [0.013, 0.331] は両方に適用されます。

4つ目の実行条件では、Opus 自身の差分に同じゲートを適用し、ゲートの寄与とワーカーの寄与を切り分けました。Nest コードベースでは 19/19 [0.824, 1.000]、React コードベースでは 19件中18件 [0.740, 0.999] でした。ここから分かることは2つあり、2つ目のほうがより有用です。

ゲートはフロンティアモデルの作業に問題を見つけませんでした。 唯一の却下は、両方の実行条件でゲートが却下した tsc の脆弱性によるものです。つまり、これらのタスクでは、ゲートは Opus に安全性を上乗せしていません。ゲートの価値は、無料のワーカーを使えるようにすることに尽きます。 高価なワーカーに対して、重箱の隅をつつくことではありません。

また、ワーカーの欠陥とプロジェクトの欠陥を切り分けるのもゲートです。 React の4件の失敗のうち、Opus が差分を書くと3件は消えます。つまり、これはワーカーの本当の欠陥です。残り1件は、7B の出力がそのタスクでは Opus と バイト単位で同一だったため、まったく同じ形で再現します。したがって、ワーカーに起因する成立率は15/19ではなく、15/18 [0.586, 0.964] です。この対照実験がなければ、小型モデルは実際に引き起こした数より3分の1多くの失敗について責められていたでしょう。なお、2つの区間はほぼ完全に重なっているため、この補正が変えるのは件数ではなく、帰属です。

得られることは3つ、コストは1つです。

1. 作業は無料です。 安いのではなく、ワーカートークンはゼロです。Opus が計画を立て、成立したものをレビューし、編集は Mac 上で行われます。
2. コンパイラーとテストスイートで確認できる作業なら、何も犠牲にしません。 19件中18件の差分は Opus が生成したものと バイト単位で同一でした。「品質が同等」ではなく、同じファイルです。
3. 間違っていれば、大きく明確に通知され、何も適用されません。 React の4件の失敗は、7回にわたって名前が変更されたシンボル（コンパイルエラー5件）、型にも影響した名前変更、モジュールパスと公開プロパティキーの変更（コンパイルエラー122件）、与えられたファイル自体の名前を変えた変更、そしてフロンティアモデルも同一の変更を生成した1件でした。それぞれ escalated と表示され、正確なエラーが示され、マージされたものはありません。Opus に直接依頼すると、差分と「他には何も変更していません」という文が返ってきます。このケースではその文は正確ですが、未検証です。
4. 実時間がかかります。 Opus を対話的に使う場合は1タスクあたり約25秒、sidecrew では 216～271秒（生成に15秒、プロジェクト独自のテストスイートと tsc に200～255秒）です。無料で無人実行できますが、速くはありません。

主張していないこと。 凍結されたルールの判定は WITHHELD です。今回の実行ではすべてのタスクが名前変更であり、タスクの少なくとも半数が null ガード、API 移行、またはデッドコード削除でない限り、ルールは判定を拒否します。測定結果はこの条件を乗り越えたのではなく、その条件が妥当であることを裏付けました。2つのフロンティアモデルと1つの7Bモデルは、Nest の19タスク中18件で バイト単位で同一の出力を生成したため、このタスクセットでは何も順位付けできません。experiments/status-quo/ には、各実行条件、実行前に凍結したプロトコル、および欠陥が含まれています。

要件

OS	Apple silicon 搭載の macOS。 ローカルワーカーは Apple の MLX です。移植版ではなく、異なる推論スタックです。
RAM	このページで測定しているローカル階層とすべての内容には、搭載 RAM が 24 GB 以上必要です。しきい値の判定には常に搭載済みの RAM を使い、空き容量は使いません。そのため、ワーカーを実行できるマシンが予告なく別の階層に切り替わることはありません。
Node	≥ 20。プロジェクト自体の engines でより新しいバージョンが要求されている場合は、それに従います（ADR-0049 で学ぶのに一晩かかりました）。プロジェクトの Node で sidecrew を実行してください。
Python	ご自身でインストールする mlx-lm：pip install mlx-lm。意図的にバンドルしていません。外部機能はシェル経由で呼び出し、doctor で報告します。ベンダー同梱はしません。
ディスク	7B モデル用に約 4 GB（初回の sidecrew serve 時にダウンロードされ、リビジョンは固定）、さらに実行中の検証サンドボックス 1 つにつき約 500 MB。
プロジェクト	tsc がほぼ正常に動作し、テストスイートを実行できる TypeScript プロジェクト。ワークロード #1 では Swift/XCTest も実行します。

24 GB 未満の場合：sidecrew は api 階層で引き続き動作し、ワーカーには Haiku を使用します。料金はご自身のキーに請求されます。 このページの数値はその階層を示していません。まだ測定されていないためです （Phase 13 §5）。サポート対象ですが、料金は未設定です。これが問題になる場合、境界は 24 GB です。

Windows および Linux：対応していません。TypeScript の検証機能は移植できますが、ワーカーは移植できません。また、メモリと負荷の検出には sysctl/vm_stat を使用します。sidecrew doctor が、予期しない形で失敗する代わりに理由を知らせます。

マシンで予想されること

チェックするのは搭載RAMであり、空きRAMではありません。Xcodeを開くと空きRAMは8 GB変動します。それに応じて動作が変わるツールでは、何が起きるかを予測できません。最低ラインは24 GBで、それを下回るとsidecrewは拒否します（ADR-0073）。

搭載RAM	ティア	ワーカー	実行中のゲート	何を意味するか
24 GB未満	—	なし：sidecrewは拒否します	—	ここでは7Bモデルを通常の作業セットと一緒に動かせません（実測済み）。無理に動かすとスワップが発生し、問題なく通っていた変更までゲートが拒否するようになります（ADR-0066）。RAM容量、最低ライン、理由が表示されます。サポート対象外の回避策（SIDECREW_TIER=api、ネットワーク経由のHaiku、料金はご自身のキーに請求、測定対象外）もありますが、このページの数値はいずれもそれを表すものではありません。
24–32 GB	local	Mac上の7Bモデル	1	このページの数値はすべてこの環境で測定しました。ワーカートークンはゼロです。一度に1タスクずつ処理するため、1件あたり約4分、19タスクのプランなら約70分かかり、無人で実行できます。メモリが制約になります。下記の偽陰性に関する注記をご覧ください。
48–64 GB	local	7Bモデル、または余裕を持って14Bモデル	約3 (推定)	ゲートがモデルとメモリを奪い合うことはなくなります。同じ19タスクのプランは約25分で完了する見込みです (推定)。また、ADR-0066で示された偽陰性のすべて、つまりメモリ不足のゲートが安全側に倒れて失敗する問題も当てはまらなくなります。マシンを使い続けられます。

実測値と推定値の違いは重要です。 24–32 GBの行は実測値です。32 GBのM2 Proで、1タスクあたり生成に15秒、プロジェクト固有のtscとテストスイートに200–255秒かかりました。48–64 GBの行は、実測した2つの値、つまり上記のタスクごとのゲート処理時間と、1つのゲートが実際に使用するメモリ量（大規模なReactプロジェクトでtscが最大8 GB、Jestワーカーが7–10 GB）から導いた推定値です。64 GBでsidecrewを実行した人はいません。並行処理数の計算はツール自身が行うため（slot_gb = model.ram_gb + headroom）、doctorがあなたのマシンで可能な処理を知らせます。

RAMを増やすと短縮できるのは処理時間と信頼性であり、変更の質ではありません。 Reactのコードベースでゲートが検出した4件の失敗のうち、メモリを増やしても防げたものはありません。1件はシンボルが何度も名前変更され、1件は指示されたファイルの名前が変更され、1件はワーカーに提示されていないファイルで宣言された型に触れ、もう1件はOpusの出力とバイト単位で同一でした。最初の2件はモデルの問題で、3件目に必要なのはRAMではなく検索機能です。

ここに記載した各生存率の数値をどの程度参考にすべきかについては、このページの冒頭をご覧ください。D = 0.105 [0.013, 0.331]で、ゲートは自身の判定に同意していません。これは、この表だけでなく、後に続くすべての率に関係するため、ここではなくページ冒頭に記載しています。

さらに2件の不具合によってゲート自体が変更されました（ADR-0067、ADR-0068）。そのため、上記のPhase 11の表は、修正が2つ適用される前のゲートで測定したものです。

---

実プロジェクトはどちらも変更されておらず、どちらも私たちのプロジェクトではありません。上記の各条件はすべて、ワーカートークンがゼロのローカルティアで実行しました。apiティアには独自の生存率、承認率、費用の数値はありません。Phase 13 §5は実施されておらず、このページの記述はいずれもapiティアを表すものではありません。 experiments/go-no-go-2a/results/REPORT.mdには、ファネル、固定されたルール、そして数値を得るために代償として判明した6件の不具合が記載されています。

テストフレームワークではありません。テストの実行にはVitest、Jest、XCTestを、コードの変更にはStrykerJS/Muterを使用します。sidecrewがオーケストレーションを担います。ランナーは接続点です。同じプラン、同じシードで実行すると、VitestとJestは同一の判定を返します（ADR-0028）。

実行コスト

ワーカーは無料です。調整にはコストがかかります。そのコストがどれほどかを示すのが、この数字です。

2026年9月19〜20日に、変更を加えていない商用 Nest/jest コードベースを対象に、プランナーの開発前に固定したルール（experiments/planner-cost/）に基づいて測定しました。

プランの規模	計画に必要な Opus のトークン数	タスクあたり	タスクごとにモデルに依頼する場合との比較
12 タスク	265,607	22,134	2.84×
41 タスク	343,144	8,369	1.07×

作業量が3.4倍になっても、計画コストはほとんど変わりませんでした — 1.29倍です。これは大きな固定コスト（コードベースの読み込み、約233kトークン）と、小さなタスクごとのコスト（約2,700）で構成されています。つまり：

12個程度のタスクでは、sidecrew の調整に費用をかける価値はありません。仕事の規模が大きくなるにつれて、経済性は sidecrew に大きく傾きます。

どちらの行も1.0を上回っているため、固定したルールでは両方とも不合格です。つまり、計画にかかるコストは、各タスクを有料モデルに任せるよりも高いままです。正直な読み取りは上の一文であって、「不合格」ではありません。片方のプラン規模だけなら、はるかに厳しく、はるかに実態とかけ離れた主張ができていたでしょう。だからこそ、ルールでは2つの規模を求めています。

プランの規模を示さずに、タスクあたりの数値を引用しないでください。 同じプランナー、同じプロジェクト、同じ週でも、数値は2.6倍違います。

修正ラウンドは無効で、その効果も測定済みです。 コンパイラー自身のメッセージを含む無料の再試行を行った後、失敗したワーカーに Opus が書いたメモを1つ渡しても、成功したタスクは**29件中0件 [0.000, 0.119]でした。また、27件は無料の再試行とまったく同じゲート段階で終了しました（experiments/correction-round/）。ワーカーがファイルを変更せずに返したタスクでは、変更せずに返すことが失敗だと明確に伝えた後も、17件中16件で同じことが起きました。この作業が該当する「null ガードの追加」では、ローカルの7Bモデルが成功したのは30件中1件 [0.001, 0.172]**で、17件ではファイルを変更せずに返しました。指示の言い換えでは変化がないため、sidecrew fix ではこのラウンドを無効にしています。

ただし、これは能力の上限ではありません。後の測定がそれを示しています。 フェーズ14bでは、同じ30件のタスクに14Bモデルを使用し、別の試行では依頼を単一の名前付き関数に絞りました。どちらも「変更せずに返す」失敗を大幅に減らしました — 14Bでは17件から3件に、依頼を絞った場合は17件から10件に減りました — しかし、どちらも成功率は改善せず、1件から2件 [0.008, 0.221] になっただけでした。作業を行うのはワーカーです。ゲートがその成果を認められないのです。 下記の「v0.1.0 にないもの」を参照してください。

ワークロード #1（テスト）について

	Claude がすべてのテストを書く場合	sidecrew
テストあたりのトークン数	各関数で全量を生成	計画 + 各形状につき1つの例 + 成功したもののレビュー
レイテンシの上限	API	使用するハードウェア — 7Bワーカーあたり40 tok/s、下記で測定
Claude が読むもの	生の出力	コンパイルに成功し、テストに合格し、1つ以上のミュータントを検出したテストのみ
生成時のネットワーク接続	必要	不要

トークン数と成功率の列はフェーズ6で測定しました。結論は単純な「はい」ではありません。experiments/go-no-go/results/REPORT.md には、テストの絞り込み、実行前に固定した判定ルール、そして特定できなかったセルが記載されています。TypeScript は条件付きで可、Swift は不可です。 速度の列を見てください。

M2 Pro、32 GB、macOS 26.6.2、mlx_lm 0.31.3、Xcode とシミュレーターの両方を起動した状態 — experiments/go-no-go/results/bench-2026-09-11.json。すべてのフィールドで "measured": true です。

モデル	デコード速度	TTFT（ウォーム時）	最大 RSS	スワップ量	同じプロンプトで5回
Qwen2.5-Coder-7B-Instruct-4bit	40.5 tok/s	159 ms	4.4 GB	0	バイト単位で同一
Qwen2.5-Coder-14B-Instruct-4bit	21.1 tok/s	199 ms	8.1 GB	0	バイト単位で同一

マシンがアイドル状態のときは、それぞれ42.3 tok/s と21.2 tok/s です — Xcode のワーキングセット全体が動作していても、7Bの速度低下は約4％で、14Bにはほとんど影響しません。Xcode が消費するのは速度ではなくメモリです。空き容量が9.1 GBのとき、14Bは3.2 GBをスワップしました。これが7Bをデフォルトにしている理由であり、ワーカーの起動時点で空き RAM を確認する理由です（ADR-0011）。

インストール

要件：インストール済みメモリが 24 GB 以上の Apple Silicon Mac。 それ未満では、通常の作業セットと並べて 7B モデルを実行できません（ADR-0009、実測済み）。sidecrew は起動を拒否し、メモリ容量、必要な最低容量、その理由を示します。計画を立てる前に sidecrew doctor で確認できます。

拒否するのは、単なる手抜きではなく、意図的な判断です。それでも実行するとスワップが発生します。スワップが発生すると、このゲートは問題のない変更を拒否するようになり、その判定結果だけでは実際の不具合と区別できません（ADR-0066、実測済み）。それを、問題を見抜く力が最も限られているユーザーに押しつけるより、拒否するほうがましです。

回避策は一つありますが、サポート対象外です。 SIDECREW_TIER=api を設定すると、同じゲートを通して、Anthropic API 経由で claude-haiku-4-5 を使ってワーカーを実行します。費用はご自身のキーに請求されます。実装とテストは済んでいますが、稼働状況やタスクあたりの費用は一度も測定されておらず、このページにある数値はどれも該当しません（ADR-0073）。doctor では「サポート対象外、オプトイン済み」と表示されます。

生成を除くすべての機能（計画、検証、確認）は、node が動作する環境ならどこでも使えます。

npm install -g sidecrew
sidecrew doctor

doctor は各機能を個別に確認します。

ok       platform         darwin/arm64
ok       node             v20.20.0
ok       tier             32.0 GB installed → local tier · qwen2.5-coder-7b-4bit
ok       mlx_lm           python3 -m mlx_lm server available
MISSING  worker           nothing on http://localhost:8000/v1 — start one with: sidecrew serve
ok       memory           32.0 GB total · 12.5 GB free
ok       tsc              Version 5.9.3
ok       vitest           vitest/2.1.9 darwin-arm64 node-v20.20.0
MISSING  stryker          stryker 8.7.1 is not in sidecrew's tool cache — run: sidecrew tools install (~62 MB, never into a project)
ok       swift            Apple Swift version 6.3.3
MISSING  muter            not installed — brew install muter-mutation-testing/formulae/muter
ok       line-ranges      from the TypeScript compiler's own tree (ADR-0076)
DEGRADED tsconfig-include sidecrew writes candidates to test/, and no file there is in the program
                          tsconfig.json builds — every candidate would be compiled by a stage that
                          never opens it (ADR-0037)
ok       ts-jest          ts-jest does not resolve here — the shim is not needed
ok       tsc-heap         this project's own scripts ask for no extra heap
ok       jest-tests       jest does not resolve here — not this project's runner

特に読む価値があるのは下の 5 行です。 いずれも失敗した実行、あるいはそれ以上に悪いことに、気づかれずに成功してしまった実行です。「インストールされていますか」という問いには、すべて「はい」と答えます。問題はその一つ下の階層、つまり個々のプロジェクトの構成方法にあります。実際に発生した 6 つの阻害要因の中で、最も深刻なのは tsconfig-include です。唯一、失敗を見逃して成功扱いした事例でもあります。コンパイル段階で候補のファイルを一度も開かずにプロジェクトの型チェックを行い、型エラーが 3 つあるファイルに対して compile ok と報告しました。

Claude Code

claude mcp add --scope user sidecrew -- npx -y sidecrew mcp

その後、claude mcp list に sidecrew: … ✔ Connected と表示され、新しい Claude Code セッションから sidecrew_status を呼び出せるはずです。スキルとエージェントをインストールすると、/sidecrew plan|run|review|escalate を使えるようになります。

cp -r $(npm root -g)/sidecrew/claude/skills/sidecrew ~/.claude/skills/
cp    $(npm root -g)/sidecrew/claude/agents/*.md     ~/.claude/agents/

同じファイル群は Claude Code プラグインでもあります。claude/.claude-plugin/plugin.json がマニフェストで、そのバージョンは package.json および server.json と連動します。

生成をローカルワーカー上で行うのはスキルの役割です。Claude Code のサブエージェントがセッションエンドポイントで選択できるのは haiku／sonnet／opus のみなので、ワーカーをサブエージェントにすることはできません。そのため、スキルにはその旨が明記されています（ADR-0001）。

その他の MCP クライアント

{ "mcpServers": { "sidecrew": { "command": "npx", "args": ["-y", "sidecrew", "mcp"] } } }

機能はそれぞれ独立しています

機能	必要なもの	ない場合
TypeScript の計画、検証、確認	node と、プロジェクト独自の tsc および**vitest または jest**。Stryker は sidecrew のものです：sidecrew tools install	—
Swift の確認	Xcode CLT、muter	TS のみ
ローカルワーカー	pip install mlx-lm（Apple Silicon）	検証のみ。Claude がテストを自ら作成

pip install mlx-lm                                          # workers
brew install muter-mutation-testing/formulae/muter          # Swift mutation

sidecrew tools install                                      # sidecrew's own pinned Stryker, once per machine

テスト対象のプロジェクトには何もインストールされません。 Stryker は sidecrew のもので、~/.sidecrew/tools にバージョン 8.7.1 が固定されています。実行ごとに、その一時コピーをプロジェクト独自のコンパイラーとテストランナーに接続して使用します。すべての run と fix では、実行の前後にプロジェクトのフィンガープリント（git status、package.json、すべてのロックファイル、node_modules）を照合し、何かが変更されていれば明確に失敗します（ADR-0088）。sidecrew doctor --project <dir> は、プロジェクト独自のテストランナー（jest または vitest）があるかどうかを報告します。この部分はプロジェクト側のものです。

ツール

ツール	機能
sidecrew_status	ワーカーは起動していますか？使用モデル、リビジョン、空き RAM、利用可能な検証器を確認します。
sidecrew_generate	1 つの WorkerTask から、ローカルモデルで候補テストを 1 つ生成します。Anthropic API には一切アクセスしません。
sidecrew_verify	コンパイル → 実行 → 1 つのファイルをミューテート → Verdict を返します。
sidecrew_run_batch	計画全体を実行します：生成 → 検証 → エラーを添えて 1 回再試行 → エスカレーション。生き残ったものとエスカレーションのみを返します。
sidecrew_plan_validate	計画を実行にかける前に、スキーマ、行範囲、source_sha を確認し、すべての例を実際に検証器で実行します。
sidecrew_escalate	ワーカーが対応できなかった内容を、与えられた例とルール、両方の試行でのエラーとともに返します。完了した実行結果をディスクから読み込みます。
sidecrew_review	確認する価値のある生き残りを選びます：言語ごとのミューテーションスコアのしきい値を下回るものに、決定論的な監査サンプルを加え、トークン上限内でまとめます。
sidecrew_fix_plan_validate	変更計画を実行にかける前に検証し、どのワーカーも合格できなかったタスクはルールに従って拒否します。
sidecrew_fix	ワークロード #2a：プロジェクト独自のテストスイートと tsc をゲートとして、動作を維持した変更を行います。候補ごとにテストスイートを実行するため、時間がかかります。
sidecrew_fix_escalate	ワーカーが変更できなかった内容を、すべての試行の判定とともに返します。
sidecrew_recon	設定どおりのプロジェクトにある tsc エラーの数と、より厳格な各フラグで追加されるエラーを、ソースとテストに分けて示します。件数を数えるだけで、修正は提案しません。
sidecrew_query	プランナーの述語に関する質問に、プロジェクト独自のコンパイラーで回答します：refs、unreferenced、sizes、diagnostics。ワーカーは使いません。
sidecrew_read	ローカルワーカーが 10 ファイル以下を読み、質問 1 つに回答します。機械が引用箇所を特定できた主張だけが返されます。採用されたことは、正しいことを意味しません。

仕組み

Claude (Opus)          sidecrew                       local worker (mlx_lm.server)
  reads module ──► test_plan.json + one exemplar/shape
                     for each function × shape ──► prompt = source + exemplar ──► candidate
                     verifier: tsc/swift build → vitest/swift test → stryker/muter
                        survive? ── yes ──► survivors (Claude reviews low mutation-score ones)
                                 ── no  ──► retry once with error ──► escalate to Claude

• 製品の要は検証器です。 生き残る ⇔ コンパイルできる ∧ テストに合格する ∧ 1 つ以上のミュータントを検出する ∧ トートロジーではない。
• ワーカーは決定論的です。 temperature は 0、シードは固定、モデルリビジョンは固定です。シードはリクエストを mlx_lm.server のバッチ処理から外す役割も担います。バッチ処理可能かどうかは is_batchable and args.seed is None で決まるため、シードを指定するとリクエストは必ず直列化されます（ADR-0003）。
• ワーカーは Claude Code のサブエージェントではなく、別プロセスです。 サブエージェントがセッションエンドポイントで選べるのは haiku／sonnet／opus だけなので、ローカルへのルーティングには MCP を経由する必要があります。docs/research/ を参照してください。
• メモリを 2 つの異なる観点から考慮します。 搭載 RAM によってティアが決まり、24 GB 以上ならローカルワーカーを実行できます。24 GB 未満の場合、sidecrew は処理を拒否し、RAM 容量、必要な最低容量、理由を示します（ADR-0073）。こうしたマシン向けに ADR-0009 で設計された api ティアは Phase 13 で構築されましたが、生存率、承認率、価格のいずれの数値も存在しないため、サポート対象から外されました。SIDECREW_TIER=api として残っていますが、doctor では非サポートと表示されます。空き RAM によって、今すぐ起動できるかどうかが決まります。serve はモデルの必要容量 + 2 GB を下回る場合、起動を拒否します。スワップを使い始めたワーカーは、単に遅くなるだけでなく、その後に測定されるすべての数値を損なうためです。また、カーネル独自のメモリプレッシャーレベルも確認します。メモリプレッシャーがかかると macOS はメモリを圧縮し、空き容量の数値が増える一方で、マシンの状態は悪化するためです（ADR-0026）。--wait を指定すると、拒否する代わりに空きができるまで待機します。

CLI

sidecrew doctor                                  what this machine can do
sidecrew models [--pin [KEY]]                    pinned revisions, what is downloaded, this machine's tier
sidecrew serve [--model qwen2.5-coder-7b-4bit] [--port 8000] [--force] [--wait N] [--allow-unpinned]
sidecrew status / stop
sidecrew bench [--determinism]                   tok/s, TTFT, peak RSS → experiments/go-no-go/results/
sidecrew plan test_plan.json [--quick]                        validate a plan; non-zero if it is not valid
sidecrew run test_plan.json [--concurrency N] [--dry-run]     whole plan, survivors out
sidecrew verify <test-file> --plan test_plan.json            one file, one Verdict, non-zero if it failed
sidecrew generate --plan P --function F --shape S            one candidate, for looking at
sidecrew escalate [RUN_ID]                                   what the workers could not do, for Claude
sidecrew review [RUN_ID]                                     which survivors are worth Claude's eyes
sidecrew fix change_plan.json [--validate | --dry-run]       workload #2a: behaviour-preserving changes
sidecrew recon [DIR] [--flags --strictNullChecks,…]          tsc errors as configured, and what each flag adds
sidecrew query refs|unreferenced|sizes|diagnostics …         predicate questions, the project's own compiler
sidecrew read --question "…" --file F [--file …]             a local worker reads; answers admitted by citation
sidecrew mcp

doctor、status、verify はいずれも、sidecrew 自体のディレクトリではなく、指定されたプロジェクトについて回答します。sidecrew doctor --project fixtures/ts-fixture は、判定の根拠となる、そのパッケージの tsc、vitest、stryker について報告します。

実行例

sidecrew serve                                   # one 7B worker, gated on free RAM
sidecrew run fixtures/ts-fixture/plans/strings/test_plan.json --dry-run   # tasks, concurrency, stale check — no tokens
sidecrew run fixtures/ts-fixture/plans/strings/test_plan.json

run 2026-09-14T10-24-26Z-strings: 6 tasks, 13.0 GB free ÷ 6.5 GB per slot = 2; 1 worker up, so 1 in flight and 2 test processes each
titleCase:happy_path:0: survived (score 0.88)
…
6/6 survived · 0 escalated · .sidecrew/runs/2026-09-14T10-24-26Z-strings/result.json

並行数は設定値ではなく、条件によって決まります。搭載 RAM によってティアが決まり、実行開始時の空き RAM によって同時に処理できる候補数が決まります。--concurrency は上限であり、マシンにないメモリを使えるようにすることはできません。

モデルの固定

mlx_lm には --revision がないため、リポジトリ ID は「今日の main の内容」を意味します。sidecrew models --pin は、Hugging Face のキャッシュに実際にあるコミットを src/models.json に書き込み、serve はそのスナップショットのパスを渡します。これはネットワークに接続できない不変のコミットです（ADR-0010）。

sidecrew serve                 # downloads on first run
sidecrew models --pin          # writes the commit it downloaded
sidecrew bench --determinism   # 5× the same prompt: byte-identical, or non-zero exit

ステータス

main で公開済み、v0.2.0 以降は未リリース： sidecrew recon（より厳しい各フラグによって tsc エラーがいくつ増えるか）、sidecrew query（参照数、参照されていないエクスポート、書き換えサイズ、位置情報付き診断 — プロジェクト独自のコンパイラーによるもの）、sidecrew read（ローカルモデルが読み取る内容、検証済みの引用によってのみ認められる主張）、リフレクションで到達可能なものへの変更を拒否するゲートルール、強化されたテスト作成ゲート、大規模なテストスイート向けのメモリ受け入れ制御。フェーズ 14d では、プランナーにこれらを使わせることで、小規模なジョブでも計画コストを十分に抑えられるかを測定しました。計画トークンは約 23％削減されましたが、十分ではありませんでした — ロードマップを参照してください。

v0.2.0 — 到達範囲（2026年9月24日）。 タスクではファイル全体ではなく宣言を 1 つ指定でき、その宣言を基準に評価されます。宣言内のエラーがゼロで、宣言外にそれより悪い状態がなく、すべてのテストが引き続き成功することが条件です（ADR-0086）。すべて、変更を加えていない商用 Nest コードベース（ソースファイル 2,174 件）で、数値が出る前に固定したルールに基づいて測定しました。

	測定結果	場所
ワーカーに変更を依頼できるコードの割合	バイト数で 0.519 → 0.911	experiments/reach/
以前は拒否されていたファイルで、タスクごとに宣言を 1 つ指定	15/41 = 0.37 [0.22, 0.53]	docs/plan/prompts/phase-14c-prime.md
以前から到達可能だったファイルで、同様に宣言を 1 つ指定	10/42 = 0.24 [0.12, 0.40]	同上
同じ 27 ファイルを対象に、ファイルごとにタスクを 1 つ指定（従来の単位）	1/27	docs/plan/prompts/phase-14c-the-reach.md

傾向として読み取ってください： 2 つの区間は重なっており、大きなファイルの区間は、このプロジェクトが実用可能と呼ぶ 0.30 のラインを下回っています。測定した中で最も難しかったケースは、--strictNullChecks の null ガードでした。まだうまくいかなかったこと： 変更前にワーカー自身がテストを書く方法（ADR-0082）では、20 件中 2 件しか成功しませんでした。実際の NestJS サービスに対して実行できるテストをまだ作れないためです。また、テスト作成ゲートに抜け穴が見つかりました（ADR-0089）。型のみのアサーションでゲートを通過できていました。v0.2.0 以降、main で対策済み — 現在は、本文の削除でもクラッシュでもないキルが必要です。

その前のフェーズ 14 — 初の公開リリース。 パイプラインは 2 つのワークロードのどちらでも、計画、ローカルワーカーでの生成、検証、1 回の再試行、エスカレーションまでエンドツーエンドで実行されます。また、sidecrew fix も動作を維持したコード変更に対して同じ処理を行います。数値が 1 つも出る前に固定したルールに基づいて 5 つの測定を行いました。率直にまとめると、そのうち 3 つはノーという結果でした：

	判定	場所
ワークロード #1、TypeScript	条件付きで go — フィクスチャでは Haiku の 0.85、ワーカートークンはゼロ、レイテンシーは半分（ADR-0020）	experiments/go-no-go/
ワークロード #1、Swift	no-go — プロンプトを修正して 2 倍以上に改善した後でも Haiku の 0.64（ADR-0021）	experiments/go-no-go/
ワークロード #2a	2 つの実プロジェクトで、ちょうどマージンゼロで go。ただし、タスクの構成がすべてリネームだったため保留	experiments/go-no-go-2a/、experiments/status-quo/
計画コスト R	どちらの計画サイズでも不合格 — タスク 12 件で 2.84、41 件で 1.07	experiments/planner-cost/
ゲート自体のエラー率 D	許容できない — 0.105 [0.013, 0.331]	experiments/gate-error-rate/

この 0.85 はフィクスチャの数値であり、実際の値を 2 倍以上に過大評価しています。 変更していない実際のプロジェクトで事後測定したところ、ワークロード #1 の生存率は Nest のコードベースで 3/8 [0.085, 0.755] および 4/8 [0.157, 0.843]、React のコードベースで 4/10 [0.122, 0.738] でした。これらの区間は互いに、またフィクスチャの区間とも重なっているため、これらの数値による順位付けは一切できません。ここから分かるのは、0.85 を前提に計画を立てるべきではないということです。フィクスチャの関数は小さく自己完結しており、実際のコードの大半を占めるインポート、共有型、フレームワークの足場がありません。 D はワークロード #2a のゲートで測定したものであり、これらには当てはまりません。ミューテーションテストは、失敗モードの異なる別のオラクルです。

このエビデンスを見る限り、14B を選ぶのは適切なトレードオフではありません。TypeScript では 7B と同等で、Swift では劣り、生成時間は 2.2 倍かかりました。

v0.1.0 にないもの。 実際のコードベースの半分は対応できません。プロジェクトのファイルの 3.3 % がバイト数の 48.1 % を占めており、1,000 行を超えるファイルはすべて拒否されるためです。ワーカーはファイル全体を返し、そのファイル全体が収まる必要があります（ADR-0075 — シンボル単位の返却が修正案として提案されていますが、このリリースには含まれていません）。

実際に対応できる変更の形。 振る舞いを維持する 5 つの変更の形のうち、実用的な成功率で機能するのは 1 つ、名前変更と未使用インポートの削除だけです。 null_guard は機能せず、Phase 14b ではその理由を測定しました。この結果により、対処方法も変わります。**S₁₄ = 2/30 [0.008, 0.221]。14B ワーカーと単一関数への依頼の中で最良の結果です。** 障害となっているのはモデルのサイズでもタスクのサイズでもありません。どちらの検証でも、対象にしたものは変更されました。**ワーカーが正しく修正したファイルが 1 つ増えるごとに、合格できないタスクも 1 つ増えました。** +6 件の正しい修正 → +6 件の充足不可能なタスク、+9 → +9 です。その理由はゲート自身のフィールドに示されています。タスクを失敗させるエラーは **21 件中 21 件でテストファイルにあり**、テスト以外のソースには **0 件** でした。null ガードは型を絞り込み、その絞り込まれた型がフィクスチャやモックにも波及します。そして **テストがゲートであるため**、sidecrew` はテストを編集できません。

したがって、正直な説明は「小型モデルにはできない」ではありません。厳格性フラグが有効で、テストが型を絞り込む変更の影響を受けるプロジェクトでは、ワーカーの性能にかかわらず、この変更の形では合格できません。しかも、ワーカーの性能が上がるほど状況は悪化します（3 つのアーム全体で、充足不可能なタスクは 12 → 18 → 21 件）。api_migration と dead_code は引き続き未測定です。ADR-0077 には選択肢が記録されており、担当者はどちらを選ぶか決める前に反実仮想を測定する方法を採用しました。

docs/plan/PHASES.md に今後の道筋と、各ステップで得られるものが記されています。

上記の説明を信じる前に読むべき測定結果が 1 つあります。 設計では、小型モデルを実用的にするのは例示コードだとされています（研究 §B）。しかし、私たち自身のアブレーションでは、例示コードなしのスコアは 4/20 で、コンパイルエラー 15 件のすべてが import { describe, it, expect } from "vitest" の不足によるものでした。このインポートについて説明する文を 1 つ追加するだけで、例示コードなしでも 16/20 を達成し、完全な例示コードを 1 上回りました。例示コードを残しているのは、生存コードのミューテーションスコア（0.93 に対して 1.00）とコスト（生成トークン 258 に対して 150）で利点があるためであり、候補をゲートに通すためではありません。ADR-0017 に表と注意点が記されています。最も重要なのは、n = 1 の場合、16/15/17 の差はタスク 1～2 件分にすぎないという点です。

長時間の実行がマシンに与える影響と、sidecrew の対策

Phase 7 の強化内容と、それぞれを提案した ADR は次のとおりです。

• 1 回の再試行は、効果が見込める場合にのみ行います。 変更を加える ツール が原因の失敗、ミュータントがまったくない関数、および最初の試行とバイト単位で同一のプロンプトになる再試行は、いずれも再試行せずにエスカレーションします（ADR-0012、ADR-0005、ADR-0022）。再試行用プロンプトには専用のテンプレートを使います。
• エスカレーションは発生時に .sidecrew/runs/<id>/escalations.jsonl に書き込まれるため、40 分後に実行が強制終了されても、各試行で得られた成果の記録が残ります（ADR-0023）。タスクが例外をスローした場合はエスカレーションし、ほかの 19 個のタスクは実行を続けます。セットアップエラーが発生した場合は、引き続きすべての処理を停止します。
• Claude が読み取るのは、すべての生存ミュータントではなく、最も弱いものです。 言語ごとのスコアしきい値を下回るものに加え、決定論的な 10 % の監査サンプルを、トークン上限内でまとめて処理します（ADR-0024）。TypeScript では 0.6、Swift では 1.0 です。Swift の判定は 1〜2 個のミュータントに基づいて算出される一方、TypeScript では 6〜12 個に基づいて算出されるためです。
• ワーカーはスワップが発生している状態では起動しません。 空き RAM だけでなく、カーネル独自のメモリプレッシャーレベルも確認します。メモリに圧力がかかると macOS はメモリを圧縮するため、空き容量の数値が増える一方でマシンの状態が悪化するからです（ADR-0026）。--wait を指定すると、拒否する代わりに空きができるまで待機します。
• マシンの性能が低下すると、ワーカー枠を減らします。 デコード速度が sidecrew bench のベースラインより 30 % を超えて低い状態が 2 分続くと、ワーカーの同時実行数を 1 つ減らします。ベンチマークがない場合は、推測で判断せず、保護機能を適用しません（ADR-0025）。
• リビジョンが固定されていない場合は警告ではなく拒否します。 同じリポジトリの異なるコミットで測定した生存率は比較できず、後続の処理ではそれを判別できないからです（ADR-0027）。

sidecrew run --dry-run は、すべてのタスク と すべてのレンダリング済みプロンプトを書き出し、最初のトークンが生成される前に停止します。

ロードマップ

sidecrew が目指すのは、オーナーの言葉を借りれば、"Claude Opus がすることを、別のより安価な方法で実現する" ことであり、どのユーザーも自分のコードでその結果を得られるようにすることです。 各リリースでは、その目標がどこまで実現したかを、数値に 実測値 または 推定値 のラベルを付けて正確に示し、それ以上の主張はしません（ADR-0093）。

バージョン	内容	状況
0.x	下記のはしごに 段階を 1 つ 追加したリリースを、実測後にのみ公開します	v0.2.0 を公開済み。main にさらに追加中
1.0	実際のリクエストを対象にしたベンチマーク（機能とバグ修正を含む）で、sidecrew の成功率が Opus 単独の ≥ 80〜90 % に達し、バッチジョブのコストがその ≤ 50 % であること（ジョブの規模に応じた誤差範囲付きの近似式として示し、単一の数値では示しません）。Opus 単独の結果を基準に評価し、sidecrew の開発対象ではなかったプロジェクトでも再現できること	未達成
2.0	Opus 単独と同等以上の速さ	—
3.0	Opus 単独と同等以上の品質	—

能力の段階

機能やバグのほとんどは固有のものではないため、作業はカテゴリに分けられ、それぞれにマシンで実行できるゲートがあります。カテゴリとして認められるのは、測定された後だけです。最後の段階である あらゆる リクエストは 1.0 です。

段階	カテゴリ	ゲート	ステータス
1	既存コードのユニットテストを作成する	コンパイルできる ∧ 合格する ∧ 本体の削除でもクラッシュでもない変異体を検出する ∧ トートロジーではない	実装済み。実プロジェクトで 3/8、4/8、4/10 を測定（厳格化したゲートで再採点中）
2	挙動を維持するクリーンアップ — 名前変更、デッドコード、未使用のインポート	差分が対象範囲内に収まる ∧ tsc がクリーン ∧ 合格していたすべてのテストが引き続き合格する ∧ リフレクションから到達可能なものを削除しない	実装済み、測定済み
3	リントとコンパイラーフラグの修正	段階 2 のゲート + フラグまたはルールがクリーン	対象群を測定済み（実際の Nest コードベースで +282、ソースの 95 %）。未実行
4	静的解析の指摘事項（Sonar 形式のルール）	段階 3 のゲート + アナライザーのルールがクリーン	提案済み
5	厳格化の移行（--strictNullChecks）	段階 2 のゲート。テストファイルの型エラーは格下げ	宣言を 1 つずつ変更し、25/83（参考値）
6	カテゴリ別のバグ修正	再現テストが失敗から成功に変わる ∧ 何もデグレードしない	未実装
7	カテゴリ別の機能	スマートモデルが作成し、ユーザーが承認した仕様テストが失敗から成功に変わる ∧ 変異に反応する ∧ 保留しておいたテストに合格する	未実装
8	あらゆるバグ、あらゆる機能、モジュール全体の新規作成	段階 7 のゲート。カテゴリ分けなし	1.0

作業の分担方法 — 期待成功コストが最も低い、対応可能な手段を優先

正確な答えを出す機械的ツール（コンパイラー、言語サービス、codemod）、次にローカルモデル、より安価な Claude モデル、最後にユーザーが利用しているモデルの順で使います。各作業は安さだけでなく期待成功コストに基づいて振り分けられ、ゲートの判定に応じて段階を上げ、すべての段階を同じゲートで評価します（ADR-0092、ADR-0094）。リクエストはまずトリアージされます。規模（変更する箇所の数）がコストを、複雑さ（結果に必要な判断の度合い）がレベルを決め、1 つのリクエストを異なるレベルの複数の部分に分割することもできます（ADR-0095）。

測定結果に基づく現在の状況

	測定対象	現在	目標
到達範囲	タスクが変更できる実コードベースのバイト数の割合	0.911（測定済み）	≥ 0.90 ✓
コスト	計画にかかる費用	小規模な作業ではまだ Opus より安くない：約 12 タスクの作業の計画には Opus 5.5 で $2.39–3.31（タスクあたり約 $0.22–0.30）、約 40 タスクの作業では $2.67–3.48（タスクあたり約 $0.07–0.08）がかかります。費用の大半は、考えることではなく、プランナーが自分のコンテキストを読み直すことに使われています（測定済み）	Opus 単独での測定を行った後、バッチ作業で Opus 単独の 50 % 以下
形状	実用的な割合で対応できる、挙動を維持する変更の形状	名前変更とデッドコードは対応済み。厳格化の移行は改善中。正式な再採点は保留中	5 項目中 4 項目以上
信頼性	ゲートの判定がどの程度一貫しないか	プロジェクトのテストスイート自体の不安定率と診断済み。回帰テストのみ失敗した場合に再確認することで緩和（ADR-0084）	診断済み ✓

次の予定（作業リストは docs/plan/HANDOFF.md を参照）：1.0 の測定対象となる、オープンソースプロジェクト外から寄せられた実際のリクエストのベンチマーク、それに必要な Opus 単独との比較、トリアージ、中位層のモデル、そしてゲートの高速化です。設計がまだ変化している間は、短いプローブで測定し、公開する数値に限って長時間の実行を行います（ADR-0091）。1.0 に至る道のりについての独立した分析は、docs/research/2026-09-25-v1-independent-analysis.md にあります。

sidecrew 自体の開発

npm i && npm run lint && npm test

fixtures/ 内のフィクスチャにはそれぞれ独自の依存関係があり、リポジトリには含まれていません。これらはビルド成果物です。そのため、クローンした直後はフィクスチャに依存する一部のテストケースがスキップされます。各スキップには、有効にするコマンドが記載されています。すべて実行するには、次のようにします。

for f in fixtures/*/; do [ -f "$f/package.json" ] && npm --prefix "$f" i; done

実際のツールチェーン（稼働中のワーカー、Stryker、Muter、プロジェクト独自のテストスイートなど）が必要なテストは、*.slow.test.ts という名前で、SIDECREW_SLOW=1 を指定した場合にのみ実行されます。CI では高速なテスト群を実行します。

リリース

simframe と同じです。package.json、server.json、claude/.claude-plugin/plugin.json を同時に更新してタグを付け、プッシュします。CI ですべての内容が一致していることを確認し、リリースワークフローで npm と MCP Registry に公開します。

ライセンス

MIT です。ワーカーモデルとツールにはそれぞれ独自のライセンスがあり、候補に含まれるのは Apache-2.0 または MIT のものだけです。 docs/research/licences.md は監査記録で、何が同梱され、何がダウンロードされ、何が単に推奨されているかを、ウェブサイトではなくインストール済みの成果物に基づいて確認できます。