結論から： デモ動画だけを見て Coding Agent を信頼しないでください。次の 7 つを確認してください。実プロジェクトで動くこと、フォルダ許可を守ること、実際の差分を見せること、安全に戻せること、コマンドとテストの証拠を出すこと、高リスク操作の前に承認を求めること、Git を前提条件にしないこと。
なぜチェックリストが必要か
AI コーディングエージェントはデモでは十分に速く、感銘を与えます。ただし、クリーンなリポジトリでのデモと、履歴のある複数フォルダのプロジェクトでの作業は異なる問題です。リスクはエージェントが何かを試すことではなく、あなたがそれが何をしたかを見られないこと、またはきれいに戻せないことです。このチェックリストは、実際の作業を任せる前にツールを評価するための実用的な枠組みです。
確認する 7 つのこと
- 実プロジェクトへのアクセス。 貼り付けるためのサンドボックスではなく、あなたの実際のリポジトリをスキャンして作業できること。Semibot： UI をフリーズさせずに背景でスキャンし、大きなコードベースはバックグラウンドプロセスで処理します。
- 複数フォルダの許可。 実際の仕事はひとつのディレクトリに収まりません。ひとつのタスクで、複数の許可済みフォルダを使えること。Semibot： 1 つの作業ディレクトリと複数の読み書き許可ディレクトリを同じタスクでサポートします。
- 変更の可視化（ChangeSet）。 触ったファイル、実際の差分、実行したコマンド、テスト結果——受け入れる前に。Semibot： すべてのコーディングタスクでその証拠を含む ChangeSet を提示します。
- チェックポイント／安全な取り消し。 Agent が行った編集は元に戻せること。後から人間や IDE が直したファイルを、盲目的に上書きしないこと。Semibot： 完全な証拠付きのファイルチェックポイントを保持し、後続の人間や IDE による編集を盲目的に上書きしません。
- コマンドとテストの証拠。 「動きます」は証拠ではありません。終了コードとテスト出力が証拠です。Semibot： すべてのタスクで実行したコマンドとテスト結果を一覧表示します。
- 高リスク操作の承認。 送信、外部への書き込み、ファイル書き込み、git 書き込みは人間のゲートを通すこと。セッション単位の自動化があっても、危険な操作は可視化されたままにすること。Semibot： 統一された承認経路を使用し、自動実行モードは危険として表示され、フォルダ許可はバイパスできません。
- Git は任意で、必須ではないこと。 git コマンドの承認が、フォルダへのアクセス許可を意味してはいけない。Semibot： Git は任意のソース管理です。git コマンドの承認がフォルダアクセスを暗黙的に付与することはありません。
並べて見る
| 確認項目 | 典型的な IDE Agent | 純粋なチャットモデル | Semibot |
|---|---|---|---|
| 複数フォルダ許可 | 単一ルートが多い | 該当なし | あり |
| 安全な取り消し | Git 依存 | 該当なし | ファイルチェックポイント |
| ChangeSet の証拠 | 差分表示 | スニペットのみ | ファイル＋差分＋コマンド＋テスト |
| 承認 | 実装により異なる | 該当なし | 統一。git 書き込みも対象 |
| Git が必要か | しばしば必要 | 不要 | 不要（任意） |
| コードグラフ | あり | なし | TypeScript ネイティブ |
| 自動実行モード | あり（さまざま） | 該当なし | あり（危険として表示） |
定性的な位置づけであり、性能の採点表ではありません。
ワークフロー例
このチェックリストを使った実際の評価フローの例です。
例 1：新入社員のオンボーディング
- 既存リポジトリのフォルダを許可します。コードグラフが背景で構築されます。
- 「この API のエンドポイント一覧を教えて」と質問します。グラフが関連ファイルを辿ります。
- 「このバグの修正案を出して」と依頼します。ChangeSet が差分とテスト結果を提示します。
- 差分を確認し、テスト証拠を見てから受け入れます。問題があればチェックポイントで戻します。
例 2：マルチリポジトリの横断修正
- フロントエンドとバックエンドの 2 つのフォルダを許可します。
- 「API のレスポンス形式を変更して、フロントも追従して」と依頼します。
- Semibot が両方のディレクトリにまたがる ChangeSet を提示します。
- 各ディレクトリの差分とテスト結果を確認してから受け入れます。
例 3：Git を使わないプロジェクトでの作業
- Git が初期化されていないフォルダを許可します。Semibot は Git なしでも動作します。
- 変更を依頼し、ChangeSet を確認します。
- チェックポイントによる元に戻しが利用できます。Git のコミット履歴に依存しません。
- 必要であれば、後から git init してからコミイルすることも可能です。
詳説：ChangeSet とチェックポイント
ChangeSet は変更の納品投影です。許可された読み書きディレクトリごとに、何が変わったかを示します。Semibot の管理ツール経由で編集されたファイルは、チェックポイントの証拠が揃っているため安全に取り消せます。その後で、あなたや IDE がファイルを直した場合、Semibot はそれを盲目的に上書きしません。コマンドレベルの完全なロールバックが必要なら、Git の worktree や隔離された実行モードと組み合わせてください。
Semibot が元に戻せるもの： Semibot の制御されたツールを通じて編集されたファイルで、完全なチェックポイント証拠があるもの。チェックポイントは変更前の状態をキャプチャし、完全な Git 履歴なしで変更を元に戻すことを可能にします。
Semibot が元に戻せないもの： あなたや IDE が Semibot の後にファイルを変更した場合、Semibot は元に戻し時に盲目的に上書きしません。チェックポイントは編集時の正確な状態にのみ適用されます。完全なコマンドレベルのロールバックには、Git の worktree や隔離された実行モードが必要です。
ここで大事なのは、「戻せる」と「戻したか分かる」の両方です。チェックポイントは前者、ChangeSet は後者を担います。どちらか一方だけの製品では、実プロジェクトでの事故のあとに原因を辿りにくくなります。
詳説：ネイティブコードグラフ
Semibot は TypeScript 製のコード知識グラフエンジンを内蔵しています。Python のサイドカーも、外部 MCP にも依存しません。呼び出し、参照、構造をつなぎ、プロジェクト全体をスキャンせずに「この変更によって他に何が影響するか」という問いに答える助けになります。
グラフがやること： ナビゲーションと影響分析です。プロジェクト内の全ファイルをスキャンせずに「この変更で他に何が影響を受けるか」をエージェントが調べる助けになります。
グラフがやらないこと： 正しさのオラクルではありません。グラフは関係性を示すもので、コードが正しいかどうかを判断するものではありません。高リスクな結論はソースコードや再現可能なコマンドに戻って確かめてください。
Git が「任意」であるべき理由
- 管理対象外のディレクトリや、Git を使っていない現場でも作業できなければ、ツールの都合を仕事に押し付けることになります。
- 「git コマンドを承認した」ことと「フォルダ全体へのアクセスを許可した」ことは別です。Semibot ではこの 2 つは分かれており、git 書き込みは承認経路を通過します。
- Git がある環境では、チェックポイントと組み合わせて二重の保険になります。Git だけに頼ると、まだコミットしていない編集の事故を防げないことがあります。
判断基準：どの Coding Agent を選ぶか
- 行単位の補完と高速な編集体験が必要な場合： IDE 中心のツール（Cursor など）が適しています。エディタのキーバインドやプラグインの深さで勝ります。
- 見慣れないリポジトリの修正を届け、レビューまで通したい場合： コードグラフと ChangeSet が有用です。Semibot はこの流れを持っていますが、エコシステムが若いため、十分な検証を行ってください。
- ファイル操作の範囲をフォルダ単位で決めたい場合： 明示的なフォルダ許可モデルが必要です。IDE の「プロジェクトを開く」とは異なる粒度です。
- Git を使わないプロジェクトがある場合： Git が任意の製品を選ぶ必要があります。多くの IDE Agent は Git を前提としています。
- コーディングと文書作成を同じツールで済ませたい場合： 作業台型の製品を検討してください。ただし、専門 IDE の深さには届かないトレードオフがあります。
このチェックリストがカバーしないこと
- モデルの品質そのもの。 どのモデルを使うかで変わるので、ここでは採点しません。
- 速度や正確さのベンチマーク。 共通の公開手法がない数字は、この文脈では役に立ちません。
- すべての事故の防止。 承認を素通りして進めれば、どの仕組みでもリスクは残ります。証拠を見てから受け入れる運用が必要です。
- すべてのプロジェクトタイプへの対応。 非常に大きなモノレポや、特殊なビルドシステムを持つプロジェクトでは、ツールの動作が異なる場合があります。自分のプロジェクトで試してください。
この方法が合わない場合
- 行単位の補完と高速な編集体験だけが必要な場合： IDE 中心のツールの方が合っています。
- コードスニペットの生成だけで十分な場合： チャットモデルで十分です。ChangeSet やチェックポイントの仕組みは必要ありません。
- 未署名の Windows インストーラを許容できない場合： Semibot は現在未署名です。署名対応まで待つか、他の選択肢を検討してください。
- Linux デスクトップが必須の場合： 現時点で Semibot は提供していません。
制約事項
- Windows ビルドは未署名です。 インストール時に OS が警告を出すことがあります。これは信頼上の障壁として認識しています。
- Linux デスクトップ版は提供していません。 ロードマップにはありますが、まだ出荷されていません。
- クラウドモデルの呼び出しにはネットワークが必要です。 ローカルファーストはデータの保存場所の話であり、オフライン推論ではありません。
- 若いプロダクトで、第三者レビューが少ない。 既存ツールよりコミュニティのカバレッジが薄いです。自分の主張で評価してください。
- コードグラフはナビゲーション用です。 正しさの検証ツールではありません。高リスクな結論はソースコードや再現可能なコマンドで確かめてください。
向いている人・不向きな人
- 見慣れないリポジトリを読み、修正を出して、レビューして、テストまで通したい人。
- ファイル操作の範囲をフォルダ単位で決め、高リスク操作で確認を挟みたい人。
- 変更の記録を後から追える形で残したいチーム。
不向きな場合： 行単位の補完と高速な編集体験だけが必要なら、IDE 中心のツールの方が合っています。また、Semibot はまだ若いプロダクトで、第三者レビューが少ない点も含めて検討してください。Linux デスクトップが必須の場合も、現時点では他の選択肢を検討してください。
FAQ
プロジェクトを壊すことはありますか？
リスクは根性ではなく、フォルダ許可、チェックポイント、ChangeSet の確認、承認で管理します。変更を受け入れる前に証拠を確認してください。
Git は必要ですか？
いいえ。Git は任意のソース管理です。Git の書き込みコマンドは承認を通り、git を承認してもフォルダへのアクセス権は増えません。
コードグラフは何に使うのですか？
道順と影響分析のためであり、オラクルではありません。高リスクな主張は、ソースかコマンドで確かめてください。
チェックポイントと Git の違いは？
チェックポイントは Agent によるファイル編集を個別に戻す仕組みで、Git のコミット履歴がなくても動きます。Git は版管理として別にあり、両方使うと二重の保険になります。
テストは自動で走りますか？
プロジェクトの慣習に合わせてコマンドとテストを実行できます。「動いた」という報告ではなく、実行したコマンドとその結果が ChangeSet に残ります。
複数リポジトリにまたがる作業はできますか？
複数フォルダの許可に対応しています。ひとつのタスクで、許可した複数のディレクトリをまたげます。
Windows でも使えますか？
macOS（Apple Silicon）と Windows x64 で動きます。Windows 版は現在未署名のため、インストール時に OS の警告が出ることがあります。Linux デスクトップ版は提供していません。
自動実行モードに切り替えられますか？
はい、セッション単位で切り替えられます。危険なモードとして表示されます。ブラウザのハードゲート、システムパーミッション、フォルダ許可は自動実行モードでもバイパスできません。
Cursor や Copilot より速いですか？
速度のベンチマークは公表していません。速度はモデル、ネットワーク、プロジェクトサイズなど多くの要因に依存します。自分の作業で評価してください。
大規模なモノレポでも使えますか？
大きなコードベースはバックグラウンドプロセスで処理され、UI をフリーズさせません。ただし、非常に大きなモノレポや特殊なビルドシステムでは、自分のプロジェクトで試すことをお勧めします。