現状と制限

実装済みの機能

出典: docs/architecture.md「実装済みの機能」．

実デプロイで確認済み / 未確認

2026-09-25 に v0.6.0 のイメージで staging デプロイを行い，staging CA で 1 つの target の発行が端から端まで通ることを確認しました．CI はサブスクリプション へのデプロイを行わないため，実インフラでの検証はこの 1 回の手作業のデプロイに 基づいています．

出典: deploy/azure/README.md「実デプロイで確認したことと，まだ確認していないこと」．新しい環境へのデプロイは，ステージング CA と 1 target から始め，最初から最後まで見守ることが推奨されています．

主な制限

Conductor 側

• 認証・認可 — プロバイダが発行した admin ロールのトークンは audience の範囲内で信頼され，失効確認やイントロスペクションは行いません．ロールは admin/viewer の 2 つだけで，target ごと・ポリシーごとの権限はありません．localhost-dev は開発ホスト 1 台向けで，人ではなくホストを認証します．
• GUI は最小限 — API の上の一覧とフォームのみで，ダッシュボードも一括操作も独自の状態もありません．
• ローカルランチャーは 1 ホスト限定 — 同じホストに acme-runner が必要で，資格情報は passthroughEnv 経由で Conductor の環境に置かれます．Container Apps ランチャーにはこの制約はありません．
• 強制終了は Runner を取り残し得る — 復旧は該当 run を「結果不明」として扱いますが，Runner はなお完了するかもしれず，次の期限到来 run と競合しえます．
• 単一プロセス・単一コネクション — レジストリはすべてのステートメントを直列化します．数百の target と 1 人の操作者には十分ですが，多忙なマルチテナント API には向きません．マルチレプリカは非目標です．
• ポリシー変更はバージョン管理も push もされない — 更新は各 target の次の run で適用され，run にポリシーのリビジョンはなく，各 JobSpec 内のスナップショットがあるだけです．
• ローカルランチャーでは署名は任意 — jobSigning なしでは生の JobSpec を渡し，end-to-end で認証するものがありません．1 ホスト上でのみ許容されます．
• メトリクスエンドポイントはまだない — /healthz・/readyz はありますが，Prometheus の /metrics はありません．

Runner 側

• ファイルシステム Store は開発・テスト専用 — 独自のアクセス制御を持たず，本物のシークレットストアの代替にはなりません．
• Key Vault store は本物の vault に対しては未検証 — vault API のプロセス内の偽物に対して試験されており，実際の取り込み動作は文書化されていますが CI では検証されていません．
• credential: default は開発上の利便性 — DefaultAzureCredential チェーンが環境変数や PATH 上の開発者ツールを使うことがあります．本番では managed-identity を指定します．
• Runner 自体には run レベルの並行制御がない — 手動や別のランチャーで開始された Runner については，同じ target への二重発行を防げません（Conductor 自身が起動する run は target ごとに最大 1 つに制限）．
• リプレイ台帳は stateDir ごと — 状態ディレクトリが別々の Runner は互いの受理済み run を見ません．jobSigning のない Runner には期限やリプレイの検査がありません．
• 署名は生成者を認証するのであって判断を認証しない — 署名鍵を持つ Conductor はどんな名前のジョブにも署名できます．それを限定するのは Runner の信頼された認可ポリシーです．
• DNS スコープの検証はできない — 渡された DNS 資格情報／ワークロード ID が実際に必要なチャレンジゾーンに限定されているかを Runner は検証できません．
• ログ秘匿はヒューリスティック — 値ベースの既知シークレット・既知 PEM マーカーのマスクであり，汎用のシークレット検出器ではありません．

非目標

次の項目は，今後 ADR が別途定めるまで明示的に対象外です．理由の多くは 「MVP のスコープを絞る」「境界の外側（すでにある実装）に任せる」ことに あります．

• ACME プロトコルや DNS プロバイダ連携の再実装 — lego がすでに行っています．
• 独自の暗号
• 秘密鍵配布 API — Conductor の中核の安全設計原則（秘密鍵を持たない）と相容れません．
• Kubernetes オペレータや CRD
• 複数レプリカ／高可用な Conductor — SQLite の単一プロセス・単一コネクション設計に対応します．
• PostgreSQL — 当面は SQLite がストアです．
• AWS または GCP のプロバイダ — バインディングモデルはこれらを見越していますが，まだ何も実装されていません．
• Arc 管理下のホストへの証明書配布
• あらゆる種類の自動 purge — ADR 0008 を参照．
• 任意のスクリプトや発行後フック
• 利用者が指定するコンテナイメージ
• 動的なプラグインダウンロード

出典: docs/architecture.md「非目標」．

設計判断の記録

アーキテクチャ上重要な決定は，MADR 風の軽量な形式で ADR （Architecture Decision Record）として記録されています．

一覧の出典: docs/adr/README.md．背景と併せて docs/architecture.md と docs/threat-model.md も参照してください．

残存リスク（要約）

脅威モデルは，未解決のまま残るリスクを明示しています．おもなものだけを 挙げます（詳細は脅威モデル「残存リスクと未対策事項」を参照）:

• ベアラートークンは期限切れまで有効で，失効確認は行いません（T14）．
• localhost-dev はすべてのループバックのピアを信頼する開発モードです（T13）．
• GitHub Actions はダイジェストではなくタグで固定されており，リリースワークフローはまだ実行されていません（T8）．
• Container Apps のピア間暗号化は文書化されていますが実デプロイでは観測されていません（T14）．
• コードベース全体を対象とするログスクラブの専用テストスイートはまだありません．

参加・問い合わせ