付録 D · 面接問題速答
ブルーブック全体を読み終えたら、この 8 問で自己テストしましょう。各問には試験ポイントと回答方針を示していますが、模範解答ではありません。面接では自分の言葉で理解を語ることのほうが、丸暗記より重要です。
概念問題
Q1：1 分で DeepSeek Harness を紹介してください。
試験ポイント：技術への感度合い。実際に使ったことがあるのか、それともニュースを読んだだけなのか。
回答方針：DeepSeek 公式がオープンソース化した Agent ランタイムフレームワークで、MIT ライセンス、コア理念は「Everything is a plugin」 — モデルアダプタ、ツール登録、セッション管理、サンドボックス実行、さらに Agent Loop 自体もすべて差し替え可能で、Cordis プラグインシステム上で動作します。LangChain のような「部品を渡されて自分で組み立てる」ライブラリと異なり、dsh は完全なランタイムで、メインループ、セッション、サンドボックス、ツールスケジューリングがすべて内蔵されています。開発者はプラグインを選んで設定を書くだけです。現在は developer preview 段階で、イテレーションが速いです。
Q2：dsh の言う「Everything is a plugin」とはどういう意味ですか？ 通常のモジュール化と何が違うのですか？
試験ポイント：アーキテクチャ理解の深さ。プラグイン化とモジュール化の本質的な違いを語れるか。
回答方針：「コードをモジュールに分割する」ほど単純ではありません。dsh のプラグイン化には三つの特徴があります。第一に、特権コアがない — Agent Loop のような最も基礎的なものさえプラグインであり、理論的には丸ごと差し替え可能です。第二に、ランタイムでの動的ロード — どのプラグインをロードするかは起動時に Profile 設定で決まり、コンパイル時にハードコードされません。第三に、可逆副作用 — 各プラグインのシステムへの変更は逆順に取り消せ、アンインストール後にシステムが綺麗に復元されます。ベース層で支えるのは Cordis の三つのプリミティブ：Service（サービス登録）、Event（型付きイベント）、Effect（可逆副作用）です。
Q3：Profile と Bundle はどういう関係ですか？
試験ポイント：dsh の設定階層を説明できるか。
回答方針：Bundle は配布単位 — npm パッケージで、ランタイムにどのプラグインと設定をもたらすかを宣言します。Profile は実行時の組み合わせ — $DSH_HOME/profiles/<名前>/ 配下に保存され、一連の Bundle の集合で「このプラグインネットワークがどう見えるか」を決めます。web、headless はいずれも Profile で、違いは重ねる Bundle が違うだけです。Bundle を「料理」、Profile を「注文済みのテーブル」と捉えると、同じ料理が異なるテーブルに載ることがあり、各テーブルの組み合わせは異なります。
Q4：dsh の四つのランタイムモードはそれぞれどんなシーンに適していますか？
試験ポイント：Web UI だけでなく、実際に異なるモードを使った経験があるか。
回答方針：Web モードは対話型で、日々の開発、デバッグ、Agent が動く様子を眺める用途に向きます。Headless モードはワンショットタスクで、実行したら終了するため、自動化スクリプト、CI/CD、定時タスクに適します。SDK モードは自分のプログラム内から呼び出す方式で、Agent 能力を既存システムに組み込むのに適します。さらに Minimal モードもあり、最もコアな Agent Loop だけを残し、ベース層のメカニズム研究や高度なカスタマイズに向きます。四つのモードは同じプラグイン層を共有し、違いは重ねる Bundle が違うだけです — これも「Everything is a plugin」の直接的な体現です。
実践問題
Q5：dsh のツール呼び出しパイプラインはどのように動作しますか？ なぜ直接実行ではなくパイプライン設計にしたのですか？
試験ポイント：コアメカニズムへの理解、設計意図を語れるか。
回答方針：モデルがツール呼び出しを要求した後、直接実行するのではなく、複数段階のパイプラインを通ります。まず pre-execute ポリシー（割り込み、変更、拒否が可能）を通過し、次に承認（権限を超える場合にポップアップで確認）を通り、サンドボックスでの実行（OS カーネルレベルの隔離で、触れるファイルを制限）に進み、実行結果は post-execute（記録、変換、監査が可能）で処理されてから、最終的にモデルへ返されます。パイプライン設計にした理由は、各段階をプラグインが割り込んで強化できることです — 監査ログを追加したい、ツールホワイトリストを追加したい、実行パラメータを変更したい、いずれもコアコードを修正せずプラグインを差し込むだけで実現します。これは実行層における「Everything is a plugin」の体現でもあります。
Q6：MCP と Skill の違いは何ですか？ それぞれどんなシーンで使いますか？
試験ポイント：二種類の能力拡張方式を区別できるか。
回答方針：MCP は外部ツールを接続する標準プロトコルです — 例えば Agent に GitHub を操作させたり、Web をスクレイプさせたり、データベースを検索させたりする「手足の能力」で、MCP サーバー経由でツール関数の集合として公開され、Agent がツールを呼んで結果を得ます。Skill はモデル向けに書かれた指示で、「この種類のタスクに遭遇したらこの手順で進め」と伝えるものです。例えばコードレビューチェックリストや週報テンプレートで、新しいツールは追加せずモデルの振る舞いを変えます。端的に言えば、MCP は Agent に「もう一組の手」を与え、Skill は Agent に「もう一冊の説明書」を与えます。外部システムとの連携が必要なら MCP、作業フローの固定化が必要なら Skill を使います。
Q7：dsh のセキュリティモデルはどのように設計されていますか？
試験ポイント：セキュリティへの関心、多層防御の考え方を語れるか。
回答方針：三層の防護があります。第一層はファイルサンドボックス — OS カーネルレベルの隔離で、JS 判定ではなく、三段階の権限：read-only（読み取り専用）、workspace-write（デフォルト、現在のワークスペースのみ書き込み可）、danger-full-access（制限なし）。第二層は操作承認 — Agent が権限を超えた操作をしたいとき、ポップアップで確認し、1 回許可は 1 回限りで永続的な許可ではありません。第三層は Key の書き込み専用化 — API Key 保存後はインターフェースに平文が表示されず、マスク済みの識別子のみ表示され、平文はローカルの .credentials.yaml にのみ存在します。コア思想は「デフォルトで制限し、必要に応じて許可する」であり、「全権限を渡してユーザーの注意に頼る」ではありません。
オープン問題
Q8：チームの技術選定を任されたら、dsh と Claude Code、Codex を比較して、それぞれ強みと弱みは何ですか？
試験ポイント：技術選定能力。盲信ではなく客観的に分析できるか。
回答方針：dsh の強み：第一に、完全オープンソース、MIT ライセンスでベンダーロックインがなく、モデルを自由に差し替えられます — DeepSeek、OpenAI、ローカルモデルいずれも動作します。第二に、プラグイン化の程度が最も高く、Agent Loop すら差し替え可能で、カスタマイズ余地が大きいです。第三に、Headless と SDK モードは自動化や統合シーンに適しており、単なるチャットツールではありません。弱み：第一に、まだ新しく、developer preview 段階で、API が不安定、ドキュメント未整備、コミュニティエコシステムが成長中です。第二に、デフォルト Web UI の体験は Claude Code、Codex と比較するとまだ差があり、多くの能力はプラグインのインストールで補う必要があります。第三に、チーム内に設定やプラグインをいじり倒す意欲のある人がいない場合、箱から出してすぐ使える体験は商用製品に及びません。選定アドバイス：カスタマイズニーズがあり、Agent インフラを自前で構築したい、多少の困難を厭わないチームなら dsh、個人で日常的にコードを書くなら安定性を重視して商用製品が無難です。