AIライブラリ
デジタル主権の二重構造
欧州の脱パランティアとアメリカン・ビッグテックの鎖
金景珍（キム・ギョンジン）, 弁護士
欧州の情報機関と国防省が米パランティアの分析ツールを排除し始めた2026年の記録です。フランス国内治安総局とドイツ連邦憲法擁護庁、オランダ国防省の置き換え決定、米国の輸出規制が同盟国の人工知能アクセスをわずか3日で遮断した事件、CLOUD ActとFISA 702条がもたらした域外管轄の実態を扱っています。欧州連合のクラウド・AI開発法（CADA）が定めた4段階の主権保証レベルと主権理由による契約解除権、ユーロスタック構想と3,000億ユーロの投資障壁に至るまで、全5章15節と結論2節で整理しました。
[AI書房] 第16章 デプロイ後の世界: メンテナンスとアップデート
Claude Code完全攻略
第4部
第16章 デプロイ後の世界: メンテナンスとアップデート
金京鎮
デプロイされた自動化の限界：自己修復が機能しなくなる地点
ブレンダーのランディングページをデプロイして二日目、実際にサイトにアクセスしてみます。問題なく動作しています。一週間後にも問題はありません。しかし一ヶ月後、スクロールアニメーションが特定のモバイルブラウザで停止し始めます。どこから手を付ければよいのかという問題が生じます。クロード・コードに「直して」と言えばよいのでしょうか？
開発段階では、クロード・コードは強力な自己診断能力を発揮します。スクリーンショットを撮影して比較し、エラーログを読み、コードを修正し、再度検証します。この反復プロセスがリアルタイムで起こるため、問題が発生すれば即座に検知して修正できます。
しかし、デプロイされたサイトでは、この自己修復ループは機能しません。クロード・コードは、お客様の開発環境で実行されるツールであり、デプロイされたサーバーを常時監視するツールではありません。サイトがベッセルにアップロードされた後、クロード・コードのセッションは終了している可能性が高いです。問題が発生しても、自動的に検知したり修正したりする主体が存在しません。
この違いを明確に認識する必要があります。開発中、AI は「能動的な守護者」としての役割を果たします。デプロイ後、AI は「依頼に応じて出動する修理屋」としての役割へと転換します。
デプロイ後に発生しうる問題の種類は、開発中のバグとは性質が異なります。
外部依存関係の変更：サイトが利用する外部 API の応答形式が変更されたり、CDN（Content Delivery Network）でホストされているフォントファイルの URL が変更されたりする可能性があります。
ブラウザのアップデート：Chrome や Safari がアップデートされることで、特定の CSS プロパティや JavaScript API の動作が変化することがあります。開発当時は完璧に動作していたアニメーションが、新しいブラウザのバージョンで崩れる事例も実際に起こります。
トラフィックの変化：突然訪問者が集中すると、画像の読み込みが遅くなったり、アニメーションのフレームが途切れたりする可能性があります。私のコンピュータホストでは私一人しか接続しないため、こうした問題を経験することはありません。
証明書とドメイン：SSL 証明書の有効期限切れや、ドメインの更新忘れといったインフラレベルの問題が発生する可能性があります。Vercel はこうした部分をかなり自動的に管理してくれますが、カスタムドメインを利用する場合は、ドメイン登録の更新は利用者の責任となります。
これらの問題に対処する基本原則は、定期的にサイトを直接訪問して確認することです。自動化ツールがない状態において、利用可能な最良の監視は人の目です。
予約実行とウェブフックトリガーの違い
サイトを定期的に確認する作業自体を自動化することはできないのでしょうか。そのためには二つの方式があります。
予約実行は、定められた時間間隔で特定の作業を繰り返す方式です。「毎日朝9時にサイトの主要ページにアクセスして応答時間を測定する」のような作業です。クロンジョブとも呼ばれるこの方式は時間ベースであり、問題が発生した時点と次の点検時点の間に時間間隔が存在するため、問題を即座に発見できない可能性があります。
Claude Codeでは、/loop コマンドを使用して簡単な予約実行を設定できます。「5分ごとにデプロイ状態を確認してください」と依頼すると、同じセッション内で繰り返しチェックを行います。ただし、このループはセッションが維持されている間のみ機能し、最大3日間持続します。長期的な監視が必要な場合は、別途監視サービスを構築する必要があります。
ウェブフックトリガーは、異なる仕組みで動作します。特定のイベントが発生した際に即座に通知を送ったり、作業を実行したりする構造です。「GitHub に新しいコミットがプッシュされると、Vercel が自動的に再デプロイする」というのがウェブフックの代表的な例です。時間ではなく、出来事に対して反応します。
両方式の違いを整理すると、以下のようになります。
実務では、両方式を組み合わせて使用します。ウェブフックでデプロイの自動化と即座の通知を処理し、予約実行で定期的なヘルスチェックを行うという具合です。
Vercel 自体が GitHub のウェブフックを活用する代表的な事例です。Vercel が GitHub リポジトリにウェブフックを登録しておくと、新しいコミットがプッシュされるたびに、GitHub が Vercel に対して「新しい変更があります」と通知します。Vercel はその信号を受け取るとすぐにコードを取得して構築し、デプロイします。ユーザーが別途設定を行わなくても、このプロセスは自動的に接続されています。
デプロイ前のバトル検証：多様な入力による検証
デプロイボタンを押す前に、もう一つの工程を踏むことで、デプロイ後の問題を大幅に予防できます。それが「バトルテスト」です。
ある開発者が決済フォームを作成しました。自分のコンピュータで名前、メールアドレス、カード番号を入力し、送信ボタンを押すと、確かに正常に動作します。そこでデプロイします。しかし、実際のユーザーの一人がメールアドレス欄に日本語の名前を入力します。別のユーザーはカード番号欄に空白を入れます。さらに別のユーザーは「戻る」ボタンを押してから再度送信します。これらのいずれかでエラーが発生し、サイトが停止してしまいます。
バトルテストとは、サイトを「正常に」使用するのではなく、「異常に」使用してみる過程です。予期せぬ入力、非論理的なクリック順序、極端な画面サイズ、低速なネットワーク環境などを意図的に試します。
Claude Codeを活用したバトルテストの方法があります。
タスクリストに検証ステップを含めることです。先ほどの章で述べたように、Claude Codeが自ら作成するタスクリストに「ウェブサイトを構築した後、スクリーンショットを撮って確認する」という項目を追加できます。同じ原理で、「さまざまなブラウザサイズでレンダリングを確認する」「空の値でフォームを送信してみる」「画像が読み込まれない状況をシミュレーションする」といった項目を追加することも可能です。
Chrome 開発者ツールを活用する方法もあります。Claude Code はブラウザを開いて直接対話できます。ボタンをクリックし、フォームに入力し、コンソールのエラーを確認します。この機能を活用して「サイトを開き、すべてのボタンをクリックし、コンソールにエラーがないか確認してください」と依頼できます。
モバイル対応の確認も欠かせません。前述の事例で、Blender サイトをスマートフォンで開いた際、モバイル最適化がされておらずレイアウトが不自然だったことをお忘れではないでしょうか。「モバイルビューポートサイズでレイアウトが正しく表示されているか確認してください」という指示をリリース前のチェック項目に含めることで、こうした問題を事前に防ぐことができます。
ベイルド検証の原則は一つです。「自分が使うときはうまくいくのだから大丈夫だろう」という仮定を疑うことです。自分とは異なる人物が、自分が想定していない方法でサイトを利用した際に何が起きるかを事前に確認します。
ワークフローとツールはデプロイするが、エージェントはデプロイしないという原則
ウェブサイトのデプロイパイプラインを理解すると、自然と湧いてくる疑問があります。「AI エージェント自体をデプロイして、24 時間稼働させることはできないだろうか？」
Claude Code を用いてワークフローを作成し、そのワークフローがデータを収集し、分析し、レポートを作成するプロセスを自動化したと仮定します。これをサーバー上に配置して、人間が介在することなく継続して実行することはできないでしょうか？
答えは「可能ですが、多くの場合、そうしない方が賢明です」です。
ワークフローとエージェントの間には本質的な違いがあります。ワークフローは定められた手順を順番に実行します。入力が入れば、定められた処理を行い、出力を生成します。その経路は予測可能です。一方、エージェントは異なります。状況を判断し、次の行動を自ら決定します。同じ入力を与えられても、文脈に応じて異なる行動をとる可能性があります。
ワークフローをデプロイすることは安全です。「毎日朝、この API からデータを取得し、この形式に変換して、このデータベースに保存せよ」といったワークフローは、手順が明確であり、失敗した際にどこで失敗したかを診断しやすく、予期せぬ行動をとることはありません。
一方、エージェントをデプロイすると、予測不能な事態が発生します。エージェントが外部 API にリクエストを送る際、応答が予想と異なる場合、エージェントがどのような判断を下すかを事前に知ることはできません。人間が傍にいれば、エージェントの判断を検証し修正できますが、無人環境では誤った判断が連鎖的に続く可能性があります。
実用的な指針は次の通りです。
デプロイすべきはツールとワークフローです。ウェブサイトのコード、スケジュールされたデータ収集スクリプト、APIエンドポイント、自動化されたビルドパイプラインなどがこれに該当します。
デプロイしない方がよいのは、判断を要するエージェントです。コードを分析してリファクタリングするエージェント、ユーザーの修正意見を解釈してデザイン変更を決定するエージェント、複数のAPIを組み合わせて複合的な作業を遂行するエージェントなどは、人が監督する環境で実行するのが安全です。
VPS（仮想プライベートサーバー）のようなリモートサーバーにClaude Codeをインストールして常時稼働させる方法もあります。ノートパソコンを閉じてもセッションが維持されるため、長時間の作業に有利です。SSH（Secure Shell）で接続したり、場合によってはスマートフォンから遠隔制御することも可能です。しかし、この場合も「人が定期的に確認する」という前提が必要です。
エージェントが単独で判断して実行することと、エージェントが作業して人が検証することの間には、決定的な違いがあります。
プロジェクトの性質によっては、この境界線は異なる場合があります。リスクが低く復元が容易な作業（例：ブログ記事のドラフト作成）であれば、エージェントにより多くの自律性を付与しても構いません。一方、リスクが高く元に戻しにくい作業（例：データベース構造の変更、決済システムの修正）については、必ず人の確認を経る必要があります。
ウェブサイトが世に公開され、アップデートのパイプラインが整備され、メンテナンスの原則が確立されました。コードを作成しデプロイする技術的な能力はツールによって支えられていますが、何を創造し、誰のために作り、どのような品質水準を維持するかという判断は、依然として人間の領域に留まっています。ツールを扱う能力が高まるほど、そのツールで何を行うべきかという問いが、より重要になっていきます。
