Yuren's Blog - 技術

OpenClawが開いた扉

Fri, 06 Feb 2026 00:00:00 GMT

「OpenClawは他のAI Botと何が違うの？」

この質問に答えるには、私がOpenClawに最初にお願いした仕事から始めるのがいいでしょう。それはお気に入りのカフェを探すことです。

私はコーヒーに特定のこだわりがあり、Google マップで一軒一軒カフェを開いて、メニューにコーヒーの産地情報や精製方法が記載されているかを確認しないと、好みのカフェを絞り込めません。だからこれはずっと悩みの種でした。他のBotもGoogle マップの店舗写真を閲覧する機能には対応していませんでした。

そこでOpenClawをセットアップした後、最初の質問も近くのカフェについてでした。次に、店内の写真やGoogleレビューを見られるか聞いたところ、その返答がとても面白かったのです。

「現在は基本情報のみを返しており、写真やレビューの内容は含まれていません。」

「必要であれば、このskillに写真とレビュー機能を追加できますが、コードの修正に少し時間がかかります。やりますか？」

この返答を見て、私は本当に驚きました。これまでChatGPTやGeminiを使っていた時、カスタマイズの余地は限られていましたし、自分のプログラムを修正して問題を解決できるBotに出会ったことはありませんでした。まるでBotがはんだごてを手に取り、自分の機械の胸部を開いて配線をやり直しているかのようです。

最終的に彼と話し合った結果、こんな成果が生まれました。

話を戻すと、「OpenClawと他のAI Botとの違い」を聞かれたら、私はこう答えます。OpenClawは「ソフトウェアエンジニアのパートナーがいて、しかもそのパートナーにパソコンを渡した」ようなものだと。パソコン上の既存のツールを使って問題を解決するだけでなく、最も重要なのはツールを作ったり修正したりできることです。手持ちのツールでGoogle マップの画像が見られないなら、プログラムを修正して画像閲覧機能を追加してしまうのです。

現在の多くのAIチャットボットはツールを提供する形式がほとんどで、それらのツールは誰かが事前に用意しなければ、ユーザーは特定のサービスにアクセスできません。しかしOpenClawは、誰もツールを提供しなくても自分で作り出します。Claude Codeのようなツールも確かにツールを作れますが、その目的はあなたと一緒にソフトウェアを協働開発することです。

一方、OpenClawがツールを作る目的は、より汎用的にあなたの問題を解決することです。

その後、私は自分のいくつかの悩みを解決し始めました。たとえば、私は各国のニュースを読む習慣がありますが、読むスピードのために、普段は中国語版のある海外ニュースサイト、たとえばニューヨーク・タイムズ、ドイチェ・ヴェレ、RFIなどを探さなければなりませんでした。しかしOpenClawを使い始めてからは、各国の原文ニュースサイトでRSSを提供しているメディアを調べてもらい、私への理解に基づいて興味がありそうなニュースを選んで中国語に翻訳し、毎朝音声のニュースブリーフィングを作成してもらうようにしました。これで朝起きたらニュースを聴けるようになりました。

さらに評価の仕組みも付けて、次回のニュース選定の参考にしてもらっています 😁

もちろん、ここで部屋の中の象に触れないわけにはいきません。OpenClawは本当にそんなに危険なのでしょうか？

これは想像しやすいでしょう。ソフトウェアエンジニアにパソコンを1台渡して（管理者権限がなくても）、その人が何をできるか、どれほど危険かを考えてみてください。エンジニアの友人にエンジニア界隈のやらかしを聞いてみてください。うっかりデータベースを削除したり、gitをめちゃくちゃにしたり、ルートディレクトリを消したり……このBotにもそういったことをやらかす可能性があります（モデル自体に多くの保護措置があるとしても）。

OpenClawの危険度はおおよそそのレベルに加えて、Prompt Injectionによって乗っ取られ、別のことをさせられる可能性もあります。私の例で言えば、もし誰かがRSSフィードやコメントに悪意のある内容を仕込んだ場合、この種の攻撃をうまく防げるとは確信が持てません。

だから、セキュリティの問題はかなり深刻だと言えます。特に独立した環境を用意せず、自分のパソコンの中で動かしている場合は、なおさらです。

しかし、それでもOpenClawが創造性と楽しさに満ちた実験であることは否定できません。AnthropicやOpenAIの実験の仕方を見ると、比較的慎重で、制御可能な範囲内でより多くのことを達成しようとしています。一方、OpenClawはその逆を行っています。もしAI Botに1台のパソコンを渡したら、どれだけ面白いことになるだろう？

それはまるでシヴァの踊りのように、破壊の始まりであり、同時に再生の時でもあるのです。

Claude Codeに受け入れテストを自動実行させる

Tue, 22 Jul 2025 00:00:00 GMT

ここ数ヶ月、CursorとClaude Codeを使って開発を続けており、LLMアシスタントがどこまで可能かの限界を押し広げてきました。その過程で、多くの開発者が直面する共通の問題に遭遇しました。

開発速度は速いが、品質にばらつきがある。うまくいくときは驚くほど良いが、失敗するときも同様に驚かされる
要件が不明確な場合、LLMが独自に詳細を補完するが、それが必ずしも意図したものではない
LLMがあまりにも速く多くのコードを生成するため、開発者の認知負荷が高まり、内容を確認する際にすべてを受け入れたくなる衝動に駆られる

様々な試行錯誤の結果、ソフトウェア開発者として、LLMとの適切な協働方法を見出しました。それは受け入れテストに立ち返ることです。長期間のAI協働作業を経て、LLMとの協働は実際の人間のエンジニアとの協働と多くの共通点があることがわかりました。要件が明確であればあるほど、議論を重ねるほど、期待に沿った成果物が得られます。

要件を明確にする方法を考えたとき、キャリア初期に学んだCucumberフレームワークとGherkin構文を思い出しました。Cucumberは振る舞い駆動開発(BDD)ツールで、人間と機械の両方が読める文書を受け入れ条件として記述します。例えば、Todoアプリケーションを開発する場合、仕様の一つとしてEnterキーを押して項目を送信する機能があります。Gherkin構文を使えば、次のように記述できます。

  Scenario: Add todo item
    When I enter "Buy milk" in the input field
    And I press the Enter key
    Then I should see "Buy milk" in the list
    And the input field should be cleared

しかし、これをどのように実行可能なテストに変換するのでしょうか。通常、仕様とテストロジックを橋渡しするグルーコードを記述する必要があります。

const { Given, When, Then } = require('@cucumber/cucumber');
const { expect } = require('@playwright/test');

// ブラウザを操作するためのページオブジェクトがあると仮定
let page;

When('I enter {string} in the input field', async function (text) {
  // 入力フィールドを見つけてテキストを入力
  const inputField = await page.locator('input[type="text"]');
  await inputField.fill(text);
});

When('I press the Enter key', async function () {
  // 入力フィールドでEnterキーを押す
  const inputField = await page.locator('input[type="text"]');
  await inputField.press('Enter');
});

Then('I should see {string} in the list', async function (expectedText) {
  // Todo項目がリストに表示されることを確認
  const todoItems = await page.locator('.todo-item');
  const itemTexts = await todoItems.allTextContents();
  expect(itemTexts).toContain(expectedText);
});

Then('the input field should be cleared', async function () {
  // 入力フィールドがクリアされたことを確認
  const inputField = await page.locator('input[type="text"]');
  const value = await inputField.inputValue();
  expect(value).toBe('');
});

以前、いくつかのサイドプロジェクトでCucumberを使用したことがありますが、本番環境のプロジェクトでは一度も使ったことがありません。主な理由は、このような仕組みの導入が容易ではないからです。チームがTDDを受け入れることさえ珍しいのに、仕様から自動テストへの橋渡しをするのは言うまでもありません。

また、私が主にスタートアップチームで働いていたことも関係しています。スタートアップでは通常、仕様からテストまでのサイクル計画を実践する時間的余裕がありません。

しかし、最大の障壁はグルーコードの記述でした。各文を個別のアクションに分解して記述するため、一つのテストシナリオが多くの小さな断片に分割されます。また、Gherkinを記述する際も注意が必要で、同じ機能の文は同じように書かないと、グルーコード内で統合できません。例えば、

When I click the button "ok"
When I go to click the button "ok"

これらは二つの異なるテストロジックの断片に分割されてしまいます。同じことをする際は、記述を完全に一致させる必要があります。

要するに、Cucumberの使用は新鮮で興味深い体験でしたが、様々な障壁により本番プロジェクトで使用したことはありませんでした。

しかし、LLMがソフトウェア開発に参入した時代では状況が変わりました。LLMはGherkinで記述された仕様を直接読み取り、グルーコードなしで直接実行できるからです。

LLMは仕様を直接読み取って理解でき、Model Context Protocol(MCP)を通じてCursorやClaude Codeがブラウザやモバイルエミュレータを操作して開発を支援できます。つまり、Gherkinで期待される動作を記述すれば、LLMはMCPを通じて開発成果が受け入れ基準を満たしているかを自己確認できるのです。

Gherkin構文は優れた橋渡し役となります。これは人間とLLMの両方が理解できる標準構文であるため、開発前にこの仕様を通じて実装内容を確認し、開発完了後にLLMがこの仕様を読み取り、MCPを使ってブラウザやモバイルを操作して受け入れテストを実行できます。詳細なデモンストレーションは、以下のYouTube動画をご覧ください。

!youtube[WvGY_Jcm_kY]

これにより、LLMとのコミュニケーションツールとして使えるだけでなく、受け入れ条件を満たしていないことを発見した場合、LLMが観察して実装を修正することもできます。

興味があれば、GitHubで試してみてください。yurenju/llm-bdd-coding-demo

BDD + TDD

BDDは、より明確な仕様と受け入れ条件により、期待通りの成果が得られない問題を軽減できますが、開発者の認知過負荷の問題は解決できません。段階的なTDDを組み合わせることで、この問題を緩和できます。

BDDを使用すると、開発仕様と受け入れ基準を明確に定義できますが、LLM開発で頻繁に遭遇するもう一つの問題があります。それは、LLMがあまりにも速くコードを生成することです。一度に生成される内容が認知負荷を超えると、誘惑に負けて確定ボタンをそのまま押してしまいますが、注意深く見ないと意図しない内容が生成されることがあります。

この認知負荷を解決するため、最近はBDD + TDDをテストしています。BDD部分は前述のようにGherkinを受け入れ基準として使用します。しかし、LLMにコンポーネントを分解してもらい、各コンポーネントの開発時に以下の順序を守るよう依頼します。

まずインターフェース、空のクラス、または空の関数を記述し、throw new Error('not implemented yet')のような未実装エラーをスローする
テストの記述のみを書いてもらう。つまり、自動テストのdescribe('記述')とit('記述')だけで、テストロジックは実装せず、確認させる
この段階で、どの程度のテストを書くつもりか把握でき、テストの粒度について直接コミュニケーションを取ります。通常、テスト項目を大幅に削減します。一般的に細かすぎるからです
テスト項目を確認した後、テストロジックを記述してもらう
テストを実行する。この時点で新しく追加されたテストはすべて失敗すべきです(レッドフェーズ)
実装を開始してもらい、実装後にテストを実行します。理論的には、書いたテストがすべてパスするはずです(グリーンフェーズ)

このような開発フローでは、各段階の成果物が認知負荷の範囲内に収まり、成果物を適切に確認できます。そして、「何が正しいか」が明確になった後は、BDDフローと同様に、明確な完了条件があればLLMは優れた成果を出せます。

このような開発フローに興味がある方は、以前書いたyurenju/cursor-tdd-rulesを参照してください。Claude Codeで使用する場合は、若干の修正が必要です。

ただし、これらはまだ発展途上の協働開発方法であることを忘れないでください。ツールや使用技術は急速に更新されており、すぐに適用できなくなる可能性もあります。

このような開発方法を使用する主な目的は、自分の認知負担を軽減し、プロジェクトを自分のコントロール下に置きながら、できる限りLLMを活用して目的を達成することです。同時に、境界と目標を明確にすることで、LLMとより良くコミュニケーションを取り、自分の目標が何であるかを伝えられます。

この過程で、開発初期から自分が何を望んでいるかがより明確になると感じています。LLMとの協働も人間との協働も、秘訣はほぼ同じです。より頻繁なコミュニケーションと要件の確認です。

おそらく人間との協働とそれほど大きな違いはなく、自分のコミュニケーション能力を強化することが重要なのでしょう。

AIにコードを書いてもらったら、理解してもらえない？

Wed, 23 Apr 2025 00:00:00 GMT

最近、会社の新しいプロジェクトのサブプロジェクトで、新しい開発方法を実験しました。できるだけ多くのコードをAI（Cursor）で書き、人間の介入を最小限に抑えることで、未来のソフトウェア開発モデルを理解しようとしています。

AIの助けを借りて開発サイクルを大幅に短縮できることを期待していました：

もしあなたも少し大きなプロジェクトでこれを試したことがあるなら、初期の結果がどうだったか想像できるでしょう：

AIに少し多くのことをやらせようとすると、期待通りに動かないことがよくありました。一度で完了できる作業は、通常、簡潔で明確で曖昧さのないタスクです。これらは通常うまくいきます。

もちろん、これでAIを使った開発をやめるわけではありません。今では80〜90%のコードをAIで開発しています。対話を通じて大量の開発を行っています。AIには深い技術力があるので、私は真剣に監督者として、彼の仕事が期待通りに完了するようにしています。

しかし、どうすればこの段階に到達できるのでしょうか？プロジェクトにAIを導入する前に、チーム内で通常どのようにソフトウェアプロジェクトを開発しているかを振り返る必要があります。

従来のソフトウェア開発の議論

従来のソフトウェア開発プロセスでは、チームは製品の観点から戦略的な議論を行い、エンジニアリングチームが技術的なソリューションについて議論します。会議と文書化を経て、最終的に合意に達した後、反復的な開発を通じて製品が徐々に開発されます。

ソフトウェア開発プロセスで重要なのは、チームの合意とコンテキストです。数語でAIに理想的なシステムを作成することを期待するだけでは、最も重要な合意とコンテキストを伝えることができません。

AIはあなたの心を読むことはできません。短い会話からこれらのコンテキストを知ることはできません。

チームは会議と文書を通じて合意を形成し、コンテキストを整理できます。では、AIにこのような情報をどのように提供すればよいのでしょうか？いくつか試してみることができます。

ルールで方向性を定義する

Cursorではルールを定義できます。質の高いルールを書くには多くの時間をかけて検討し改善する必要がありますが、ルールはAIに大まかな方向性を示し、チームのスタイルにより近づけることができます。

たとえば、テストを書くべきか？どの程度まで書くべきか？どのようなgit commit messageを好むか？コンポーネントの記述規則、命名規則、採用する技術スタックは何か？これらを説明しないと、彼はしばしば好き勝手にします。チームに加わったばかりで、開発文化にまだ適応していないソフトウェアエンジニアのようなものです。

仕様（Spec）を分割し、段階的に進む

実装前に機能仕様を書きます（もちろん彼に書いてもらいます）。仕様を十分に読んで議論し、彼がやりたいことがあなたがやりたいことと同じであることを確認してから、実装を依頼します。

機能仕様をすべて自分で書く必要はありません。私たちの場合、通常、プロジェクト管理サービス（Asanaなど）でタスクを作成した後、私がそのタスクで何をすべきかを伝え、仕様を書いてもらいます。その後、展開された仕様について議論し更新し、仕様が完成したら新しいChat Contextを開いて、その仕様に従って実装してもらいます。

仕様の質が良くないと感じたら、specを生成するruleを修正し、チームが今後specを生成する際により良い文書品質が得られるようにします。

仕様の長さはチームの習慣によって異なりますが、短い方が読みやすく、私たちの意図に沿って開発しやすくなります。これは目標をより良く達成するのに役立ちます。

前述したように、コンテキストや合意がないと、望む製品を作ることは非常に困難です。Ruleを通じてコンテキストと合意を確立することに加えて、この問題を回避する別の方法は、目標を設定した後、すべての仕様を一度に書かずに、完成しようとしている機能の仕様だけを書くことです。

彼が書いたspecに基づいて進む方向を修正するため、specを書いて実装するたびに偏差を修正できます。これにより、プロジェクトがアイデアから実際の製品への道を予想される方向に進むことができます。

仕様には受け入れ条件が必要

仕様の内容はチームごとに異なりますが、受け入れ条件（Acceptance Criteria）を含めることをお勧めします。この受け入れ条件は、AIに何が完了したかを明確に伝えるためのものです。このような明確な条件により、AIはどの程度まで完成させる必要があるかをより具体的に知ることができます。

受け入れ条件にはさまざまな方法があります。エンジニアの観点から見ると、単体テストや統合テストなどの自動化されたテストや検証で代替できます。また、Webアプリケーションを開発している場合は、microsoft/playwright-mcpを使用してAIにブラウザを開いて現在の結果を確認するように指示し、Webページを操作して検証させることができます。

現在の成果をより適切に判断できれば、完成度を判断し、後続のアクションを取ることがより簡単になります。

自動検証ができない場合は、手動テストの方法をリストアップしてもらい、開発者が自分で検証してから結果を伝えることもできます。もちろん、彼が自分で検証し、自分で修正できる方が良いです。

これまでのところ…

私たちもこのような開発モデルを試している最中で、このプロセスで調整が必要な部分が多くあります。現在、rules -> spec -> implementationというワークフローはまずまずうまく機能していると感じています。specを書く際にAIと議論し、計画を更新する機会があるため、作業を開始する前に、私たちが完成させたい形に調整できます。

しかし、Cursorがルールを守るのがあまり得意でないという問題にも直面しています。時間が経てば、これらの問題は徐々に修正されるか、より良い実践方法が蓄積されるはずです。しかし、その日が来るまで、私たちは頻繁にルールを修正する必要があります。現在、ルールが長すぎると忘れがちになり、明確で短い方が良いと感じています。また、ルールの記述も重要です。なぜなら、AIが特定のルールを適用したいと思うタイミングに影響するからです。

また、最近多くの人がVibe Codingについて話しています。これは、ほぼ直感的な方法で対話を通じて開発し、実装の詳細をあまり気にしないというものです。

しかし、実際には「直感」の大部分は、ある分野で深い背景知識と経験を持っているために、労せずして「直感」で完成させることができるように見えるだけです。実際には誰もができることではなく、表現力も関係しています。

この段階に達するには、操作する人がその製品の分野について十分に深い見解を持ち、十分に繊細で明確な表現力を備えている必要があります。

私は、誰もが自分の視点から、AIと一緒にソフトウェアプロジェクトを協働開発する方法を見つけるべきだと思います。ソフトウェアエンジニアであり好奇心旺盛な人として、また長年の執筆で一定の表現力を蓄積してきたため、私に適した方法でAIと協働し、ニーズをより正確に記述し、作業を分割し、受け入れ条件とソフトウェア開発の好みを設定し、自動化テストの方法を使用してAIがより良い仕事をできるようにします。

私は自分の視点から出発し、自分が何が好きで何が得意かを理解し、AIとのワークフローをカスタマイズしました。この相互作用の中で、コードを書くことよりも製品を作ることの方が好きだということに気づきました。AIと対話することで、この2つをより明確に分離し、自分自身を理解する機会が得られました。

そして、誰もが異なります。私のアドバイスは、自分が何が好きで何が得意かを振り返り、AIと協働する適切な方法を見つけることです。自分自身を理解することに近道はなく、誰もが多くの時間をかけて探求する必要があります。

もしあなたの興味が自分でコードを書くことであり、そのプロセスが幸せをもたらすなら、AIを使わない方があなたにとって最善かもしれません。浦沢直樹のインタビューでは、AI絵画についての見解が述べられています。彼は言います：「私は絵を描くことがとても楽しいと思っていて、私のように仕事の中で楽しみを見つけられる人にとって、AIに任せてしまうのはもったいないと思いませんか？」

大衆が追求しているものが、必ずしもあなたに適しているとは限りません。自分がどのような人間で、何に情熱を持っているかを振り返り、自分自身の視点で次のステップを踏み出す必要があります。

AIが人の言葉を理解できなくても構いません。あなた自身を理解しようとすることの方が重要です。

Claude Desktop内で直接トークン取引を行う

Thu, 13 Mar 2025 00:00:00 GMT

対話型AIツールは当初、外部情報へのアクセスが一切できませんでしたが、後に検索機能などの外部ツールが徐々に追加されるようになりました。しかし、「検索」という機能は範囲が広く、天気予報や株価照会といった特定の機能に対しては、ネット検索でも実現可能ですが、やはり直接APIを統合して天気や株式市場の機能を追加する方が効率的です。

振り返ってみると、インターネット上のサービスは数え切れないほど存在し、全てをAPIで接続することは不可能です。さらに、一部のツールはHTTP APIの形式ではなく、ローカルコンピューター上でのみ利用可能なツールです。例えば、プログラミングの際、エディターがブラウザの正確な画面、構造、開発者デバッグ情報にアクセスできることが望ましいですが、これらはHTTP APIの形式では接続できません。

MCPは、AIがツールの使用方法を理解するためのオープン標準です。例えば、タスク管理を支援してもらいたい場合、AsanaのMCPを使用してAPI経由でタスク管理サービスに接続すれば、プロジェクト全体の計画、必要なデータの作成、さらにはタスクの依存関係の管理などを支援してもらえます。

先ほど例に挙げた開発支援のためのブラウザ操作も、mcp-playwrightを使用することで、ブラウザを操作し、コンソールを直接読み取ってエラーを判断し、自動修正することが可能です。

ちょうど仕事で関連するタスクがあり、関連事項を調査する必要があったため、ProtocolinkとMoralisを使用してUniswapのMCPを作成し、Claude Desktop内で直接取引できるようにしました。

デモはこちらのYouTubeリンクでご覧いただけます。

完成後、ここ10年のメッセージングアプリの発展について考えさせられました。最初期はLINE MINI AppとTelegram Mini Appsが普及し始めましたが、後に大部分の機能は外部Webページで実装され、ごく一部の簡易UIのみがメッセージング会話内に埋め込まれるようになりました。私も同じアプローチを取るでしょう。結局、外部サイトでの実装の方が簡単で、最も必要なユーザー認証部分だけをLINE内で処理すれば良いのですから。

数か月前、VercelのAI SDK 3.0を見た時、将来のソフトウェアユーザーインターフェースが大きく変わる可能性があることを実感しました。その発表には、天気を尋ねた後、直接天気表示インターフェースを生成できるツールが含まれていました。

最初は完全に動的なUI生成だと思いましたが、ドキュメントを詳しく読むと、実際にはUIを事前定義する必要があることが分かりました。

まだそこまで実現していないとしても、ある想像の余地が開かれました。将来、UIコンポーネントが受信データのコンテキストに基づいて動的に適切なUIインターフェースを組み立てられるようになったら、どのような体験になるでしょうか?今後のユーザーインタラクションが現在とまったく異なるものになったら?音声対話の後、完全に動的に適切なユーザーインターフェースが生成されるようになるのでしょうか?

私たちの業界では、どのような影響が生じるのでしょうか?

未来を投影したり想像したりすることは興味深いことだと思います。未来は混沌としていながらも面白そうですが、面白い要素の方が多くあってほしいと願っています。

あとがき

このuniswap-mcpは研究目的のためだけに作成されたもので、コードの99%は全てCursorによって書かれました。私たちは皆、環境変数を通じて秘密鍵をプログラムに渡すべきではないことを知っていますが、それでも興味がある方のために、以下にソースコードを公開します。テストと研究目的でのみご使用ください。また、多額の資金を入れないようにしてください。

https://github.com/yurenju/uniswap-mcp

Perplexity Cometブラウザのリリース前に

Tue, 25 Feb 2025 00:00:00 GMT

Perplexityが新しいブラウザ「Comet」をリリースしようとしている。実際にどのようなブラウザになるかはまだ分からないが、想像してみるだけでも興味深い。このブラウザが人間とAIが協力してウェブを利用するものだとすれば、例えば何か資料を探したいときに、AIが各種検索エンジンで検索し、情報を読み取って整理してくれる。Google ドキュメントやNotionを編集する必要があれば、直接ウェブページを開いて文書を更新してくれる。もしそうなれば、かなり大きな変化になるだろう。

以前、なぜ人型ロボットを作るのかという理由を聞いたことがある。それは、世界全体が人間を基準に設計されているからだ。階段、ドアノブ、洗濯機、テレビのリモコンなど、すべてがそうだ。新しい創造物が別の形態であれば、何百年、何千年と積み重ねられてきたこれらのインフラを操作することができない。

このブラウザも、それに似ているように思える。従来のウェブサービスは、機械がアクセスしようとすると、新しいAPIを開発する必要があった。さらに、様々な自動化クローラーに対抗するため、reCAPTCHAのような人間検出システムまで設置されていた。

しかし、これからのブラウザが人間とAIが協力してウェブを利用するものであれば、一気に多くのインフラが利用可能になる。自動化操作の障壁はもはや存在せず、人間の介入が必要な場合にAIが協力を求め、それが完了すれば再び作業を続ける。こう想像すると、未来の世界はまったく異なるものになる。以前はウェブサービス間の統合が難しいと思われていたことが、一気に簡単になる――同時に、私たちは多くの新しい問題も解決しなければならないだろう🤣

未来はやはり混沌としていて面白い。混沌よりも面白さの要素が多いことを願っている。

ChatGPTは好奇心の反射と拡張である

Mon, 29 Apr 2024 00:00:00 GMT

独創性の根源は好奇心である。問題と答えの関係と同様に、優れた問いそれ自体が答えの重要な構成要素であるならば、好奇心もまた独創的な力の一つである。— Paul Graham¹

最近、私はChatGPTを日常的に大量に使用している。自分の記事の校正、ノートを取る際に反対意見を提示してもらうこと、様々な疑問に思うことをChatGPTを通じてさらに理解を深めることなど、もちろんその答えを疑うことも少なくない。使えば使うほど、ChatGPTはある種の投影であると感じるようになった。それは博識だが時折細部で間違える対話機械のようなものだ。しかし、あなたが話しかけなければ、疑問を解決してくれることはない。

あなたが問いかけたときにのみ、この対話機械は整然と答えを整理して返してくれる。

『浦沢直樹 × 米山舞スペシャルお絵描き対談』のインタビューで、浦沢直樹はAI描画ツールについての見解を述べている。その中で、アニメで壮大な夕日のシーンを描く際、手描きでは非常に多くの時間がかかるため、AI描画が役立つと述べた。しかし、その前に、自分の頭の中でその壮大なシーンについて既に想像を持っていなければ、その後AI描画を補助的に使うことはできないという。

「頭の中にイメージがなければ、それも意味がない」と浦沢直樹は言う。

振り返ってみると、私が普段ChatGPTを使用する際も、それに役割を設定している。例えば、ノートを校正するための役割は「あなたは厳格な編集者で、私のノートに対して反対意見や批判を提示し、ノートの内容をどう修正すべきかを提案する」というものだ。しかし、役割を設定するとき、あなたは必要な機能や視点をそれに付与していることになる。つまり、あなたは自分自身の拡張された役割と対話しているのであり、それがより大量の知識を持っているだけなのだ。しかし、その視点、役割、そしてそれが行うべきことを設定するのはあなたであり、これらの設定こそが真の独創性を与える場所なのである。

好奇心に満ちた人として、絶え間なく様々な質問を投げかける。難題に直面したとき、自分が確立した拡張された役割と対話し、反復の循環の中で自分の見解をますます理解していく。表面的にはChatGPTを使用して答えを求めているが、その背後にある力の源泉は好奇心と問いかけである。

私にとって、ChatGPTは好奇心の投影と拡張である。最終的に、重要なのは背後にいる問いかける人なのだ。

周欽華が翻訳した『How to Do Great Work』のFacebook投稿から引用し、若干の文言を調整した ↩

tw-did 補足情報

Thu, 08 Feb 2024 00:00:00 GMT

前回の記事で、このプロジェクトの協力構造がやや複雑であることに触れました。誰かに聞かれるたびに説明に多くの時間がかかるため、ここに記録しておくことで、今後は皆さんにこの短い文章を直接参照していただけるようにします。

このプロジェクトの発端は、実は数位発展部(Ministry of Digital Affairs)が発注した入札案件であり、開拓文教基金会(Frontier Foundation)が落札しました。開拓文教基金会内でこの案件に参加したメンバーの多くはDA0コミュニティ出身です。この入札案件には実際に多くのプロジェクトが含まれており、その中の一つがW3C DIDs(Decentralized Identifiers)と行動自然人憑証(Mobile Citizen Digital Certificate)を連携させる検証プロジェクト、つまり私が参加しているこのオープンソースプロジェクトです。しかし、私は入札案件には参加していません。これが複雑な部分です😎

前述の通り、私はEthereum Foundationからの招待を受け、同財団のGrant Programに採択されました。これは、財団内の有志が、このような分散型アイデンティティと政府機関との統合機会は非常に稀であり、オープンソースかつ公共の利益に適う方法で成功させたいと考えたためです。そこで、協議の結果、財団はこのプロジェクトに技術支援を提供することになりました。この技術支援の方法は、Grant Programを通じてこのプロジェクトの計画と実装を担当する適切な人材を見つけることであり、私はこうしてこのプロジェクトに参加することになりました。

したがって、この技術支援の枠組みの下で、私は財団のGrant Programに採択され、プロジェクトの設計、計画、開発を含む技術支援を提供し、最終的にソースコードを開拓文教基金会に引き渡して入札案件を完了させました。私は単独でこのプロジェクトを開発したわけではなく、他の数名の開発者もフロントエンド開発やデプロイメントなどの作業に参加しています。詳細はREADMEのcontributorsセクションをご覧ください。

つまり、私の視点から見ると、オープンソースプロジェクトに参加し、Ethereum Foundationから助成金を受け取ったということです。私は開拓文教基金会との契約関係はなく、入札案件にも参加していません。単にEthereum Foundationの助成プログラム参加者として、このプロジェクトに技術支援を提供し、オープンソースプロジェクトを開発しただけです。

この助成プログラムは12月末に終了し、その後1月中旬に、数位発展部の豆泥氏から、今後のTaiwan Digital Identity Wallet草案について、2週間の技術的実現可能性評価を提供することに興味があるか尋ねられました。この時点で初めて、私は顧問として数位発展部の草案技術評価に参加し、この顧問業務も1月末に終了しました。

したがって、もしあなたがDA0のNoahがこのプロジェクトを担当したという情報を聞いたなら、それは正しいです。Noahはこのプロジェクトにおいて、主に調整業務、広報、交流活動の大部分を担当しました。また、Ethereum Foundationがこの開発作業を支援したという情報を聞いたとしても、それも正しいです。なぜなら、私は技術支援としてこのプロジェクトの計画と開発に参加したからです。

この説明で、皆さんがこの複雑な協力関係を理解していただければ幸いです🤣

概念実証：プライバシー優先の台湾住民デジタルアイデンティティ

Sun, 04 Feb 2024 00:00:00 GMT

W3C DIDsシリーズの記事では、最初の記事「Facebookの不当なアカウント停止から見るデジタルアイデンティティの問題とDID解決策」で、現在一般的に使用されているデジタルアイデンティティがGoogleやFacebookなどの大企業に掌握されており、彼らがユーザーの許可や同意なしにデジタルアイデンティティを削除できることを指摘しました。第二の記事「W3C DIDs：権力構造を解体するデジタルアイデンティティ標準」では、W3C DIDs標準を出発点として、DIDsとVC標準を通じてデジタルアイデンティティの自律性とプライバシーの問題をどのように解決するかをより深く掘り下げました。第三の記事「Semaphore：プライバシーを強化するアイデンティティソリューション」では、Semaphoreのような最先端技術が匿名かつ検証可能な開発キットをどのように提供するかをより深く理解しました。

本記事では、これらの情報を統合して、私が昨年下半期に開発したプロジェクトについて説明します。

Ethereum FoundationのPhiniからの招待に感謝します。私は2023年下半期に財団のGrant Programを受け、複数の協力者と共に台湾のモバイル自然人憑証、W3C DIDs/VC、Semaphoreゼロ知識証明フレームワークを統合した実験的プロジェクトtw-didを開発し、集中型デジタルアイデンティティソリューションが現在抱える自律性とプライバシーの問題を改善しました。

このプロジェクトは現在、数位発展部に移管されています。このプロジェクトの協力構造はやや複雑ですので、詳細については後続の短文で補足します。

まず、これまで言及していなかったモバイル自然人憑証について紹介します。

モバイル自然人憑証

台湾で納税申告を行う際、最も便利な方法はオンライン納税申告を直接利用することです。その身分確認方法の一つが自然人憑証です。自然人憑証はチップカードで、セキュアチップに秘密鍵が保存されており、カードリーダーを通じて署名と検証を行い、台湾住民のデジタル証明書として機能します。

カードをまだ持っていない住民は、戸政事務所で直接申請する必要があります。役所が実体カードを発行した後、このチップカードを使って他の公的機関のサービス、例えばオンライン納税申告サービスを利用できます。

自然人憑証は安全ですが、実体カードの欠点は、使用するためにチップカードリーダーが必要なことです。このチップカードはNFC非接触読み取りにも対応していますが、ほとんどの場合、挿入式カードリーダーを使用する必要があります。コンピューターで使用する場合は追加のカードリーダーが必要であり、スマートフォンでの使用も困難です。

モバイル自然人憑証は、このような不便さを解決するために開発されました。モバイル自然人憑証は自然人憑証の拡張ソリューションです。モバイル自然人憑証アプリをダウンロード後、Android端末はNFCを通じて自然人憑証カードの情報を読み取り、この実体カードをスマートフォンと紐付けることができます。以降は、スマートフォンアプリを自然人憑証カードとして直接使用できます。

検証時には、指紋や顔認証などの生体認証で保護され、ロック解除後にセキュアハードウェア内の秘密鍵を使用して署名と身分確認を行います。

モバイル自然人憑証は実体チップカードの不便さを解決し、スマートフォンだけで台湾住民としての身分を検証できます。利便性を目標とするならば、確かに大きな問題を解決しました。さらに、生体認証デバイスを使用し、パスワードを記憶する必要がなく、スマートフォンのセキュア領域に秘密鍵を保存するため、セキュリティも十分です。指紋や顔認証データがスマートフォンから離れないことと合わせて、全体的にバランスの取れたソリューションと言えます。

もちろん、モバイル自然人憑証も集中型の身分確認ソリューションであり、以前の記事で述べた現行の身分確認ソリューションの主な問題である自律性とプライバシー性の観点からこのソリューションを検討できます。

その前に説明すべきことは、ユーザーがモバイル自然人憑証を使用して機関で台湾住民としての身分を検証する際、内政部のAPIを使用して検証手続きを行うということです。

自律性

モバイル自然人憑証は非対称暗号を使用して身分確認を行いますが、このサービスの発行者は検証手続きにも参加しています。これは、政府が特定の台湾住民をブロックしたい場合、検証手続きでAPIを呼び出す際にブラックリストを通じて検証サービスの提供を拒否できることを意味します。

極端な例を挙げると、外国のクレジットカード会社が台湾住民のクレジットカード申請をサポートし、モバイル自然人憑証を検証方法として統合したとします。台湾が将来全体主義国家になり、以前に発行したすべての台湾住民憑証を取り消した場合、この外国のクレジットカード会社が元の台湾住民の申請を受け入れようとしても、政府はブラックリストを通じて、政府が好まない人物が検証を通過できないようにすることが容易にできます。

プライバシー性

これは自律性の問題と根源が同じです。発行者が検証プロセスに参加しているため、ユーザーが検証を行うたびに政府が知ることになります。これは以前は大きな問題ではありませんでした。なぜなら、モバイル自然人憑証は政府機関のみが検証手続きに使用できたため、一般市民は政府機関が同じく政府機関へのログイン行動を追跡することを受け入れられたからです。

しかし、2023年下半期以降、公告によると、モバイル自然人憑証の適用範囲が非公務機関にまで拡大されました。この時点でプライバシーの問題はより慎重に考慮する必要があります。将来、オンラインバンキングのログインなどのサービスがモバイル自然人憑証サービスを通じて身分を検証する際、政府は各ユーザーがログイン行動を行う際のデジタルフットプリントを記録でき、これによりデジタルフットプリントの収集が民間企業にまで拡大されます。

上記の論点は政府を悪く想像しているように見えますが、実際にはそうではありません。Blocktrend（區塊勢）のポッドキャストのあるエピソードでHsu Ming-En（許明恩）とDouNi（豆泥）の対談でも、新しい技術が適切なガイダンスなしに導入されると、技術が必ずしも普遍的に認められた価値観に向かって進むとは限らないと述べられています。政府が持つ権力は非常に大きいため、技術の方向性を適切に導かないと、容易に方向性が誤ってしまいます。

フレームワークとメカニズムを設計する機会があるときは、できるだけ早く技術フレームワークを良い方向に進むように設計すべきです。自律性とプライバシー優先に設計できるのであれば、その方向に進むべきです。

TW-DID実験プロジェクト

モバイル自然人憑証について説明したので、ようやくこのプロジェクトを紹介できます。tw-didは実験的プロジェクトで、モバイル自然人憑証、W3C DIDs/VC標準、Semaphoreゼロ知識証明フレームワークを統合し、プロジェクトの成果から未来の姿を垣間見るとともに、現在の不足点を検証します。

前述のモバイル自然人憑証に依然として存在する自律性とプライバシー性の問題について、tw-didはモバイル自然人憑証を統合することで、台湾住民の資格憑証を連携してW3C VC形式の憑証に変換し、この2つの問題を解決できます。さらにSemaphoreを通じてプライバシー性をさらに前進させ、検証手続き時に完全にデジタルアイデンティティを開示する必要がないようにします。

次に、W3C DIDs/VCの統合とSemaphoreの統合の2つの部分に分けて説明します。

W3C DIDs/VC統合

tw-didはウェブサービスを提供しています。このサービスはまずモバイル自然人憑証を通じてログインし、ユーザーの台湾住民としての身分を検証します。次にユーザーのDID身分識別を検証します。この2つの情報が両方とも検証に成功すると、検証可能クレデンシャル（Verifiable Credential, VC）形式の憑証をこのユーザーに発行し、ユーザーが台湾住民であることを証明する必要がある他のウェブサイトでこの憑証を使用できるようにします。

「W3C DIDs：権力構造を解体するデジタルアイデンティティ標準」で紹介したように、発行者も保有者も異なるDID Methodを採用できますが、実験環境をシンプルにするため、tw-didプロジェクトではすべてイーサリアムブロックチェーンのDID Method did:ethrとイーサリアムアカウントをDID身分識別として採用しました。DID身分を検証する際には、イーサリアムの一般的な検証方法であるSign-In with Ethereum（SIWE）を使用し、MetaMaskのメッセージ署名を通じてユーザーが実際にそのアカウントを所有していることを検証し、そのDIDの秘密鍵を所有していることを証明します。

モバイル自然人サービスを通じて保有者が台湾住民であり、そのDID識別を所有していることを確認した後、発行者としてのtw-didはVC形式の憑証をユーザーに発行できます。発行時、tw-didは発行者DIDを使用してその憑証に署名し、保有者が憑証をダウンロードして保管できるようにします。全体的な発行フローは以下の通りです。

発行フローのステップ2では依然として内政部APIを呼び出し、ユーザーの身分証番号を提供していますが、これは保有者の身分を開示する唯一のAPI呼び出しであり、検証フローではどの保有者が検証を行っているかは開示されません。

銀行がW3C DIDs/VC標準の検証フローをサポートしていると仮定すると、ユーザーはこの憑証を提示して、自分が確かに台湾国民であることを証明できます。フロー図は以下の通りです。

銀行などの検証機関がユーザーに特定のVC形式の憑証の提供を要求する際、暗号学的チャレンジを一緒に提出します。ユーザーがこのリクエストを受け取ると、自分のDIDに対応する秘密鍵を使用して暗号学的チャレンジに対する応答を行い、元のVC憑証、チャレンジ、チャレンジ応答（つまり署名）をすべて検証可能プレゼンテーション文書（Verifiable Presentation, VP）にパッケージ化して銀行に返信します。

銀行は次に、VP形式の憑証の各項目の内容が正しいかどうかをチェックし、さらに発行者に取り消しリストを要求します。特定の憑証が取り消されているかどうかをAPIで問い合わせるのではなく、取り消しリスト全体を一度に取得し、検証者が自らリストからその憑証の取り消し情報を見つけます。これにより、発行者はどの保有者が現在検証を行っているかを知ることができませんが、取り消されているかどうかは確認できます。

最後に、内政部のAPIは呼び出されません。これは内政部が検証フローに参加しないことを意味します。

検証が成功し、銀行がユーザーが台湾住民であることを確認した後、銀行のサービスを使い始めることができます。同様に、このアーキテクチャ下でのデジタルアイデンティティの自律性とプライバシー性を検証しましょう。

自律性

銀行がVP形式の憑証を通じてユーザーの身分を検証する際、VP文書内の元のVC憑証には既に発行者の署名が含まれています。銀行は公開情報を直接利用して発行者の署名を検証でき、発行者の参加は不要であるため、検証フローを阻止することもできません。

発行者は憑証を取り消しとしてマークできますが、それでもこの憑証の発行者署名は有効です。なぜなら、署名の結果は否認不可能だからです。これは、憑証が取り消されても、検証者は依然としてこの状況の憑証を採用するかどうかを自ら決定できることを意味します。

上図の状態のように、VCの各状態は個別に検証されます。有効期限の検証は発行者署名の検証に影響せず、憑証が取り消されても発行者署名の検証には影響しません。

前述の極端な例を挙げると、台湾が将来全体主義国家になり、元の住民身分をすべて取り消した場合、検証者がユーザーの取り消された憑証を受け取った際、依然としてそのような憑証を証明として採用するかどうかを検討でき、すべての権力を発行者に委ねることはありません。

発行者が全検証フローに参加する場合と比較すると、W3C DIDs/VC仕様のフローはより高いデジタルアイデンティティの自律性を持っています。

プライバシー性

これも発行者が検証フローに参加しているかどうかに関連しています。ユーザーが銀行でVC形式の憑証を提示する際、発行者は知ることも追跡することもできません。これにより検証フロー中のプライバシー性が保護されます。

通常のW3C DIDs/VCアーキテクチャ下では自律性とプライバシーが既に保護されています。次に、Semaphore統合がどのようなメリットをもたらすかを見てみましょう。

Semaphore統合

Semaphore統合は通常のW3C DIDs標準検証手続きと比較して、DID識別を開示しない場合でも資格の検証の目的を達成できます。

tw-did実験プロジェクトの場合、通常のVC憑証内には保有者のDID識別文字列（イーサリアムアカウントアドレスを含む）が記録され、そこから公開鍵情報を解析してこのVC憑証が正しいかどうかを検証できます。

しかし、これはユーザーのイーサリアムアカウントアドレスが開示されることも意味します。

Semaphore統合では、DID識別を完全に提供する必要なく、台湾住民の資格があることを証明できます。モバイル自然人憑証の例に適用すると、ユーザーはイーサリアムアドレスを開示することなく台湾住民としての身分を検証できることを意味します。

しかし、前の記事で述べたように、SemaphoreはW3C DIDsのような標準ではなく開発キットです。そのため、tw-did実験プロジェクトで行った作業は、SemaphoreをW3C DIDs/VC標準に統合しようと試みることでした。より良いアプローチは、例えばdid:semaphoreのような新しいDID Methodを確立し、各種相互作用方法を制定することですが、時間と実装の難易度を考慮して、まずdid:webを使用してsemaphore検証方法をパッケージ化し、実験的評価案としました。

Semaphore統合の発行フローでは、ユーザーがモバイル自然人憑証サービスを通じて台湾住民としての身分を確認した後、ユーザーはクライアント側でSemaphore Identityを生成します。この身分識別は公開部分と秘密部分で構成されます。

公開：Commitment、非対称暗号の公開鍵部分と同様の機能
秘密：TrapdoorとNullifier、非対称暗号の秘密鍵部分と同様の機能

公開されたcommitmentはtw-didに提供され、Semaphore Groupに追加され、台湾住民資格の証明として機能します。tw-didに登録されたすべてのcommitmentsリストは誰でも取得でき、公開データです。

Semaphore検証プロセスでは、銀行などの検証者が暗号学的チャレンジを発行し、台湾住民資格を持つSemaphore Identityのみが正しいチャレンジ応答を生成できます。

ここには2つのステップがあります：証明の生成と検証。証明の生成は保有者のクライアントで実行され、検証は検証者のサービスで行われます。

保有者が証明を生成する際、暗号学的チャレンジ、自分のSemaphore Identity、資格を満たすすべてのcommitmentリストが必要であり、そのうちcommitmentリストはtw-didに要求する必要があります。この3つの入力パラメータがあれば、対応する証明を生成できます。

検証者が検証する際は、2つの入力パラメータが必要です。1つ目は保有者が提出した証明、2つ目もcommitmentsリストです。この2つのパラメータがあれば証明を検証できます。

通常の非対称暗号とSemaphoreゼロ知識証明の証明検証フローを比較してみましょう。

通常の非対称暗号は秘密鍵を使用して署名し、検証者は対応する公開鍵を取得して検証する必要があります。公開鍵はDIDの鍵ペアを表すため、DID身分情報は一定程度露出します。一方、Semaphoreの検証フローでは特定の身分に対応する特定のcommitmentを提供する必要はなく、資格を満たすすべてのcommitmentsリストのみが必要です。これにより、身分を開示せずに検証を行うことができます。

これは通常のW3C DIDs/VCと比較してプライバシー性がさらに強化されており、検証時には相手が資格を満たしていることしか分からず、具体的に誰であるかは分かりません。通常のVC憑証には必ず公開鍵情報が含まれているため、例えばイーサリアムアカウントを検証者に知られたくない場合、この高度なSemaphoreゼロ知識証明を通じて強化されたプライバシー保護を達成できます。

ただし、Semaphore統合は非常に実験的な統合であるため、開発においていくつかの近道を取っており、現在この試作品のデジタルアイデンティティ自律性は通常のVCほど良くありません。しかし、これは明確に改善方法が分かっている問題であり、これについては後述のレビューと考察セクションで議論します。

デモ動画

今回の試みとして、各マイルストーンのリリース時にデモ動画を添付しました。今振り返ると非常に興味深く、8月から10月までのプロジェクトの変化がこれほど大きいとは思いませんでした😎

各マイルストーンの紹介と動画はこちらで見ることができます：https://github.com/moda-gov-tw/tw-did/releases

ここではMilestone 6の動画を引用します：

{{< rawhtml >}} Your browser does not support the video tag. {{< /rawhtml >}}

ここには2つのタブがあります。Webタブは発行者、SampleVerifierタブは検証者です。

Webタブでは、まずモバイル自然人憑証サービスを通じてユーザーの身分を検証します。このサービス連携では、ユーザーが既にインストールしているモバイル自然人憑証アプリを通じて通知が送信されるか、ユーザーがQRコードをスキャンしてログイン手続きを行うこともできます。

ログイン完了後、Sign-In With Ethereumを通じて署名方式でユーザーが実際にイーサリアムアカウントを所有しているかどうかを検証し、最後のステップではSemaphore身分識別を生成し、そのcommitmentをtw-didのデータベースに登録します。

これで発行手続きの準備作業が完了しました。

最後に、ユーザーは2種類の異なるVC憑証をダウンロードできます。1つ目は保有者のイーサリアムアカウントアドレスに発行されるVC憑証、もう1つは保有者のSemaphore Identityに発行されるVC憑証で、ファイル名はそれぞれvc-ethereum.jsonとvc-semaphore.jsonです。

次は検証手続きのサンプルページSampleVerifierです。このページは開発とデバッグを目的としているため、やや簡素です。検証ウェブサイトは上記で発行された2種類の、それぞれイーサリアムとSemaphore用の憑証を検証できます。

イーサリアム憑証の検証部分では、まずユーザーにイーサリアムアドレスをDIDとして発行されたVC憑証を選択させます。ユーザーはファイル選択機能を直接使用してvc-ethereum.jsonを選択して検証するか、「Select on DID」を押して発行ウェブサイトで必要なイーサリアム憑証を選択できます。選択後、解析作業が開始され、検証を押すとMetaMaskで署名し、VP文書を生成して保有者の資格を確認します。

Semaphore憑証の検証部分では、Semaphore Challenge and verifyを押すと検証ウェブサイトがリアルタイムで暗号学的チャレンジを生成し、保有者はクライアント側で証明を生成してVC形式の憑証にパッケージ化し、検証ウェブサイトに返送して検証手続きを行います。

レビューと考察

GitHubのコミット記録を見ると、8月初めに最初のcommitを行い、10月末にプロジェクトを完成させました。このプロジェクトについて知る前は、DIDに関する理解は非常に浅かったため、研究も開発も非常に急ぎの状況下で完成させました。

そのため、研究と実装には不足点があることは避けられず、多くは学びながら進めました。一部の知識はプロジェクト終了後にようやくより良い方法を知ったため、ここに記して将来の開発者の参考にします。

このプロジェクトの最も重要な目標はいくつかあります：

この試作品は未来のシナリオの想像を提供し、将来の正式環境でどのようなことができるかの理解を助けるか？
これらのメカニズムが統合された際、デジタルアイデンティティの自律性とプライバシー性は保護されているか？
開発過程で正式環境の参考となる問題に遭遇したか？

試作品は未来のシナリオの想像を提供するか

この実験で統合したのはモバイル自然人憑証であり、発行された憑証は別の検証サービスによってこのユーザーが台湾住民であるかどうかを確認できます。

将来、この台湾住民の憑証は多くのサービスで身分検証の審査資料として使用されることが想像できます。例えば、銀行口座の開設や、ECサイトが売り手が台湾住民であるかどうかを審査する際などです。

しかし、試作品であるため、現段階では当然ながら検証単位がこの憑証を信頼することはありません。将来の正式環境の憑証は、内政部や数位発展部などのより正式な機関が発行する必要があり、検証機関のこの憑証への信頼度を高めることができます。さらに正式な場面で使用するには法的根拠が必要になる可能性もあります。

憑証の保管面では、将来複数の異なる憑証を保管する必要がある場合、この目的を達成するためのVC Walletアプリが必要になるでしょう。

デジタルアイデンティティの自律性とプライバシー性

前述したように、集中型デジタルアイデンティティには自律性とプライバシー性が欠けており、モバイル自然人憑証サービスにも同じ問題があります。検証機関（特に非公務機関）がモバイル自然人憑証を検証手段として採用した場合、自律性とプライバシー性の両方に懸念があります。例えば、先ほどの例のように、銀行口座を開設する際、政府が検証手続きを直接ブロックして特定のユーザーが口座を開設できないようにする自律性の懸念、同時に政府はユーザーがどの銀行で口座を開設したかを知ることができるプライバシーの懸念があります。

モバイル自然人憑証と連携してVC憑証を発行した後、検証時に発行者が参加する必要がない特性により、デジタルアイデンティティの自律性とプライバシー性が保護されます。

自律性の面では、発行者が検証手続きに参加しない（取り消しリストを除く）ため、検証手続きをブロックして人のデジタルアイデンティティを抹消することができません。取り消し機能を通じて憑証を取り消しとしてマークしても、発行者がこのデジタル憑証に署名し、承認したことを否定することはできません。

プライバシー性の面でも同様に、発行者が検証手続きに参加しないため、発行者はどのユーザーが検証手続きを行っているかを知ることができません。

もちろん、研究と開発では多くの問題に遭遇しました。以下でいくつかの関連経験を共有します。

開発キット

まず、このプロジェクトで使用したのはVeramoというTypeScriptの開発キットです。このプロジェクトを開発した経験から見ると、Veramoは非常に柔軟で、使用するのも難しくありません。今回の開発では、新しい署名検証方法Semaphore2023を実装しました。プロセスはやや複雑でしたが、最終的には完成しました。

ただし、これらはまだ比較的新しい開発キットであり、W3C DIDs/VC関連の開発者はReactやVueなどの人気フレームワークほど多くの関心を集めていないため、ドキュメントはそれほど充実していません。そのため、組み込み機能以外の機能を開発する際は、ソースコードを読みながら進める必要があります。

プロジェクトの時間が比較的タイトだったため、最初にキットを選択する際にあまり深く研究しませんでした。その後、SpruceIDがRustで実装したSpruceKitやCeramicが実装した別のTypeScriptライブラリceramicnetwork/js-didなど、いくつかの異なる開発キットを見つけました。これらは試す価値のある選択肢のようです。特にjs-didはWebAuthnをdid:keyに統合する機能があるようで、より深く研究する価値があります。

Walletの欠如

実装時には、発行者が発行した憑証を保管する適切なVC Walletが見つかりませんでした。もともとは迅速にWalletを実装する予定でしたが、時間の関係で完成しませんでした。GitHubで、フロントエンドインターフェースだけが書かれ、ロジックはまだ実装されていないwalletアプリを見つけることができます。最終的に、検証手続きの憑証選択機能を発行者のウェブサイトに組み込みました。これは実際には発行者が検証手続きに参加しないという原則に反しますが、実装時に適切なVC Walletが見つからなかったことを考慮すると、これは受け入れ可能な実験的手法と言えます。

当初は適切なものが見つかりませんでしたが、プロジェクト終了後にMicrosoftが通常二要素認証に使用しているMicrosoft AuthenticatorがVCの保管機能をサポートしていることを発見しました。詳細についてはこの記事を参照してください。

もっと早くMicrosoft Authenticatorにこの機能があることを発見していれば、彼らの統合方法を参考にして、憑証をMS Authenticatorアプリに保管できるようにしたでしょう。

交換プロトコルの欠如

当初W3Cのドキュメントを読んだ際、憑証の交換方法が規定されていませんでした。そのため、発行者が保有者に憑証を発行することと保有者が検証者にVPを提示することの両方が定義されていませんでした。定義がないため、最も直感的な方法は憑証ファイルを生成してユーザーにダウンロードさせることであり、検証者も同様にウェブページのネイティブファイル選択機能を通じてVCを提出し、ユーザーに署名させた後にVPに変換させることでした。

Microsoft Authenticatorを研究している際に、アプリが使用している交換プロトコルが別の組織OpenIDが制定した標準openid-vcとopenid-vpであることも発見しました。

当初の実装は依然として実験の目的を達成していましたが、実際に正式な製品を実装する際には、OpenIDが制定した標準を採用することを検討でき、MicrosoftのMicrosoft Authenticatorを憑証を保管するVC Walletとして使用できます。

Semaphoreはプライバシー性を向上させるが、実装の詳細には改善が必要

Semaphore統合を通じて確かにプライバシー性が大幅に向上しましたが、実験であるため、実装の詳細には多くの改善が必要です。

例えば、did:webというDID Methodを使用し、その中に新しい検証タイプSemaphore2023をパッケージ化しました。ここは実際にはVeramoを通じて新しい検証タイプを拡張し、同時にGitHub Pages上で匿名のDID身分識別did:web:tw-did.github.io:hiddenを確立しました。ここでより良い方法は、新しいDID Method did:semaphoreを追加し、匿名身分識別をネイティブサポートすることかもしれません。

同時に、他のキットがSemaphore2023というこの特殊な検証タイプをサポートしない問題にも遭遇します。例えば、前述のMS Authenticatorは、私たちが独自に定義したこの検証タイプを使用できません。全体の仕様をよく考え、DID Specification Registriesに登録して普及させることがより適切でしょう。

また、検証手続きの実装は自律性の原則に違反しており、発行者に公開情報であるcommitmentsリストを要求しました。公開情報を要求するため、プライバシー性に問題は生じません。しかし、発行者は依然としてcommitmentsを提供しないことを選択して、すべての人が自分の身分を検証することをブロックできます。

この問題はSemaphoreのオンチェーンバージョンを使用することで解決できます。オンチェーンバージョンを使用すると、スマートコントラクトと直接相互作用して多くのことを達成でき、発行者にcommitmentsリストを要求する必要もありません。これにより自律性の問題を解決できます。もちろん、発行メカニズムでブロックチェーンを使用する必要がある場合、取引手数料の支出問題など、他のブロックチェーン特有の問題も派生します。

要するに、SemaphoreをW3C DIDsに統合する実装の詳細にはまだ多くの改善すべき点があり、より成熟した方法を見つけるにはさらに多くの反復と議論が必要かもしれません。

結論

全体的に見て、この実験プロジェクトは素晴らしいと思います。重要なシナリオである台湾住民身分の検証を通じて未来の姿を垣間見ることができ、この問題に関心を持つ人々（つまり、この記事をここまで読んでくれたあなた方）に、より自律性とプライバシー性を持つデジタルアイデンティティについて、より具体的な輪郭を提供しました。同時に、実装部分も十分に進んだため、将来の正式環境で遭遇する可能性のある障害を理解できました。

一方で、ゼロ知識証明を通じて匿名かつ資格検証可能なレベルを実現したい場合、現在必要な技術が備わっているかどうかをより深く探求しました。また、このような高度なプライバシーを備えた技術が私たちにとってどれほど重要か、また他の負の影響があるかどうかを考える刺激にもなりました。

もちろん、私にとっても素晴らしい探求でした。私自身、以前はDIDをそれほど理解していませんでしたが、このプロジェクトで初めて本当に深く理解することができました。

今年の私の計画は小規模なサービスやアプリの独立開発であり、DIDやブロックチェーンとは関係ありませんが、以前の開発経験が少しでも役立つことを願っています。そのため、DIDというテーマについて誰かと議論や交流したい場合は、私に連絡してください。このテーマに少し時間を割くつもりで、プロジェクトを開発する時間はありませんが、既存の経験や見解を交流することは問題ありません。メールでのご連絡をお待ちしています！

Semaphore：プライバシーを強化するアイデンティティソリューション

Fri, 02 Feb 2024 00:00:00 GMT

コンサートに行く際、紙のチケットさえ提示すれば会場に入ることができます。本人確認が必要な場合は身分証明書の提示を求められることもありますが、紙のチケットを使えば、スタッフが本人確認を行いながらも、あなたの行動が記録されることはありません。

しかし、デジタル生活においては状況が異なります。

デジタル生活において本人確認が必要な場合、ほぼ例外なく、あなたの認証行為が記録されます。同じ例で言えば、コンサート会場で電子チケットを提示する際、入場情報が記録される可能性が非常に高いのです。

多くの場合、これらの記録には意味があり、ユーザーも理解し受け入れています。例えば、チケットの不正使用を防ぐためには、入退場記録が必要です。しかし、デジタルフットプリントの追跡が容易という特性は行き過ぎており、多くの迷惑な現象が生じています。最もよく見られるのは、ウェブサイトを閲覧した後、FacebookやGoogleに関連広告が溢れることです。まるで路上を歩いていると、後ろから誰かがノートを持ってあなたに密着し、あなたの一挙一動を記録し、コンビニで手に取った雑誌や好きな飲み物を記録しているようなものです。そして、あなたが通る道に、彼が売れると思う広告を繰り返し貼り付けるのです。

これまで、ログインと認証の実装方法は、追跡されにくくすることを考慮していませんでした。なぜなら、効率性、評価のしやすさ、追跡のしやすさこそがデジタル記録の長所だからです。しかし、人々がデジタルフットプリントがプライバシーに与える重要性を認識し始めて初めて、私たちが現在よく使用しているデジタル技術には、追跡されにくいという特性がないことに気づくのです。

そして、Semaphoreはこのような背景から生まれたメカニズムなのです。

Semaphoreは、暗号学におけるゼロ知識証明（Zero Knowledge Proof, ZKP）を用いて実装された認証メカニズムです。従来のデジタル認証では、明確にあなたの識別情報を入力する必要があります。例えば、Googleアカウントにログインする際は、アカウント名とパスワードを入力する必要があり、アカウント名自体があなたの識別情報となります。

Semaphoreの使用シナリオでは、アカウント名のような情報を入力する必要はありません。代わりに、資格のみを検証し、ユーザーの具体的なデジタルアイデンティティは検証しません。チケット販売プラットフォームのシナリオを使って、3つの異なる技術実装でこの概念を説明しましょう。

例のシナリオ

紙のチケット

紙のチケットを使用する場合、Aliceはチケット販売サイトで購入した後、紙のチケットを入手します。イベント会場で、スタッフのBobにチケットを提示すると、Bobはこのチケットが正しいかどうかを確認し、正しければAliceを参加させます。

紙のチケットには固有の欠点があります。例えば、偽造を防ぐために追加の偽造防止措置が必要であり、このようなシナリオでは通常、QRコードスキャン検証などの電子チェック手段を使用して、1枚のチケットが2回使用されることを防ぐことができます。ただし、電子チェックメカニズムを採用する場合、一般的にはユーザーの足跡も記録されます。

デジタルチケット

デジタルチケットを使用する場合、Aliceはまずアカウントでチケットプラットフォームにログインし、チケットを購入する必要があります。購入が成功すると、Aliceは観客リストに追加されます。イベント会場に到着したら、スマートフォンにQRコードを表示して入場し、BobがQRコードでチケットを検証した後、Aliceを入場させ、システムにAliceのチケットが入場済みであることをマークします。

デジタルチケットの利点は、検証がより便利であることです。技術的な問題を克服する必要がありますが、入場時にバックエンドのデータベースを通じて観客が出席者かどうかを迅速に確認でき、複数の人が同じチケットで入場しようとしても検出できます。

欠点はデジタルフットプリントの問題です。合理的に使用する分には問題ありませんが、現在の状況では濫用されすぎており、特に広告においてそうです。

Semaphore認証

Semaphoreは、匿名でありながら検証可能なログインメカニズムを開発者が作成するのを支援する開発キットです。まず同様に、チケットプラットフォームにログインしてチケットを購入する必要がありますが、ここではチケット販売プラットフォームはユーザーにSemaphore Identityを登録させます。名前を入力する場合、チケット販売プラットフォームは依然としてユーザーの名前と対応するID番号を知っています。例えば、Aliceが登録すると、彼女のID番号0x1234は依然として彼女の名前Aliceに対応しています。

イベント当日、Aliceが入場する際、同様にQRコードを提示して入場しますが、このQRコードにはユーザーの明確な認証情報（アカウント名やメールアドレスなど）は含まれていません。代わりに、検証側が暗号学的チャレンジを提示し、ユーザーは身元を明かすことなくチャレンジの解答を返します。この解答は出席者の1人だけが答えることができ、これにより自分が出席者であることを証明しながらも、実際に誰であるかは明かしません。

これは、チケット検証時に、出席者リストにはuser1、user2、user3、user4のような情報のみが表示され、これらはそれぞれ4人の出席者を表しますが、userNと実際の出席者のID番号の対応関係はプラットフォームでは知り得ないことを意味します。

Aliceの検証が成功すると、プラットフォームは、入場可能な4人の出席者のうち1人が入場し、まだ3人が入場していないことしか知りません。実際に誰が入場したかについては、検証側は知る由もなく、このチケットは使用済みとしてマークされ、他の人が同じチケットで入場することはできません。

これらの機能の実装は、すべて暗号学におけるゼロ知識証明技術に基づいており、暗号学によってユーザーの資格を検証しながらも、具体的な身元を明かす必要がないことを保証しています。

これはW3C DIDs/VCメカニズムと比較しても、プライバシー保護能力がさらに強化されています。VC検証時には避けられずユーザーの公開鍵が漏洩しますが、Semaphoreはいかなるユーザー識別情報も漏洩しません。

Semaphoreを使用する理由とシナリオ

前述のように、現代でよく使用されるデジタル認証技術は、避けられずユーザーの身元を開示します。これらの記録が結び付けられた後に生成されるデジタルフットプリントは、個人のプライバシーの開示に対する大きな脅威です。付きまとうような迷惑な広告だけでも十分煩わしいのに、ユーザーが2つの全く異なるアカウントのプラットフォーム、例えばソーシャルネットワークサイトとブログサイトのようにアカウントに共通点がない場所を切り替えても、広告が至る所に追いかけてくることができるのです。これらのことは極めて煩わしいものです。

さらに懸念されるのは、ウェブサイトの侵入事件です。ハッカーがウェブサイトに侵入し、ユーザーがそのウェブサイトに多くのデータと足跡を残している場合、これらのものは詐欺や次の侵入の材料として、境界のないインターネット上に拡散されます。例えば、私自身はインターネットを使用する際、比較的注意深い人ですが、Google Oneのダークウェブ監視機能では、私のデータが大量に漏洩していることが確認でき、これらの多くはウェブサイトが侵入された後、ダークウェブで販売されたものです。

Semaphoreのような技術を使用するウェブサイトが増えると、ウェブサイトに保存されるデータが最小化され、ウェブサイト自体もユーザーのデジタルフットプリントを識別できない状況下では、たとえデータが盗まれても用途がなくなります。

もちろん、このような匿名でありながら検証可能な技術は、すべてのシナリオに適用できるわけではありません。チケット購入以外に、Semaphoreを認証として使用できる例をいくつか挙げますが、Semaphoreはプライバシー問題しか解決できず、通常、例の中には多くの複雑な状況を処理する必要がありますが、ここではプライバシー問題にのみ焦点を当てます。

オンラインでのアルコール購入

一般的にオンラインでアルコールを購入する際、個人のプライバシー識別情報を知られたくありませんが、年齢情報を検証する必要があります。特定のサービスで身元を検証した後、成年資格を持つ人は全員、Semaphore規格の資格証明を取得できれば、今後オンラインでアルコールを購入する際にこの証明を提示するだけでよく、具体的な身元識別によって追跡されることはありません。

ここで年齢を検証する際、資格を満たしているかどうかしか分からず、具体的な身元は分からないため、販売業者側もプライバシーデータを保存しません。もちろん、身元検証を提供するサービスは依然としてプライバシーデータを持っていますが、攻撃面ははるかに小さくなります。

内部告発者プラットフォーム

セクハラやその他の内部告発者プラットフォームでは、通常、そのユーザーが特定の事件を報告する資格があることを検証する必要がありますが、匿名性を保つ必要もあります。会社がプラットフォームに登録する際、従業員をsemaphore身元としてシステムに登録する必要があると想像してください。報告が必要な場合、Semaphore身元検証は、検証可能でありながら匿名性を保つ身元検証方法として機能します。

例えば、セクハラ防止プラットフォームで報告する際、報告者が本当にその会社で働いたことがあることを確認できますが、匿名性を保つことができます。

薬物または困窮者支援

一部の薬物支援や困窮者支援は、社会に長期的な汚名化問題がある場合、同様の方法で解決できます。例えば、Semaphoreを通じて支援資格リストを確立できますが、支援を受け取る際には実際の身元を提示する必要はなく、支援を受ける資格があることを確認できます。

意見調査

意見調査（または電子投票）も、身元を検証する必要がありながら、意見を発表する際には匿名性を保つ必要があるシナリオです。ただし、意見調査で解決すべき問題は依然として多く、プライバシーはその中の1つの大きな問題に過ぎず、さらに多くの問題を解決する必要があります。この議題について、Tom Scottのyoutube動画『Why Electronic Voting Is Still A Bad Idea』を見ることをお勧めします。

以上は私が考えたいくつかの例ですが、一般的に言えば、匿名でありながら資格検証が必要なシナリオであれば、Semaphoreを開発キットとして採用できます。

結論

Semaphoreは、ゼロ知識証明を用いて構築された開発キットとして、実際にはプライバシーにおいて多くの異なる応用が可能です。もちろん、プライバシーが向上すれば、それはプラットフォーム側の権力を制限することを意味します。

前回の記事『W3C DIDs：権力構造を解体するデジタルアイデンティティ標準』の反響の中で、印象的なものがありました。彼は、このようなユートピア的なメカニズムは美しいが、誰も使わないだろうと述べていました。実は私も部分的に彼の意見に同意しています。なぜなら、このようなメカニズムは確かに巨大企業の参加者が投入しなければ、成功を収めることは容易ではなく、巨大企業がなぜすでに大きな権力を握っている自らの権力を制限する必要があるのでしょうか？

しかし、デジタルフットプリントと個人のプライバシーの問題は、すべての人に深く影響を与えており、徐々に各方面の注目を集めています。例えば、EUのGDPR（EU一般データ保護規則）は、プライバシーデータの使用をより厳格に制限し始め、最近ではEUデジタルアイデンティティウォレット（The European Digital Identity Wallet, EUDIW）もW3C Verifiable Credentials 1.1標準を採用し、さらに国家を超えた法規制と監督の観点からプライバシー保護を強化します。

一方、プライバシーで利益を得ることに比較的依存していないAppleも、近年、アプリ追跡許可を導入し、ユーザーが自らデジタルフットプリントをアプリに開示するかどうかを決定できるようにしており、これらはすべてデジタルフットプリント問題を徐々に修復する兆候です。

私は比較的悲観的な人間ですが、これらのプライバシー関連の進展が世界を急速に変えることはないという意見にも同意します。しかし、これらの進展を見ると、まだ少しの希望を持つことができます。ジャイアンがいつものび太をいじめているからといって、先生に彼はジャイアンを理解していないと悲観的に言うことはできません。多くの人の見方や習慣を変えることは非常に困難なことですが、私も能力の及ぶ範囲で少しでも支援を提供できればと思います。

話を戻すと、Semaphoreは開発キットとして、その機能は開発者がよりプライバシー原則に適合した認証メカニズムを開発できるようにすることですが、W3C DIDsのような標準ではなく、より基礎的な開発キットであるため、開発者がより完全なプライバシー優先の認証メカニズムを構築する必要があります。

現在、いくつかのプロジェクトが徐々にSemaphoreの認証メカニズムを導入しています。

例えば、zuzalu passport (zupass)は、研究会/イベントの認証プラットフォームとして、Semaphoreをzupassの認証インフラストラクチャの基盤として採用し、Proof-Carrying Data (PCD) SDKを資格証明ソリューションとして公開しています。zupassは軽量なDIDソリューションのようなものですが、特にW3C DIDs/VC標準に準拠しようとはしていません。

また、UniRepは、匿名の評判システムとして評判を受け取ったり付与したりすることができ、同様にSemaphoreを基礎的な身元識別ソリューションとして採用しています。

全体的に、Semaphoreは依然として非常に新しいソリューションであり、開発者の観点から見れば、Semaphoreはすでに認証に使用されるゼロ知識証明フレームワークを非常に使いやすくパッケージ化していますが、これらの暗号学技術は依然として最先端分野であり、開発者は技術全体の概念を理解する必要があり、同時に実験的な試みを通じて開発キットのさまざまな側面を慎重に評価する必要があります。

したがって、Semaphoreが大規模に応用されるまでには、まだ道のりがありますが、このようなプライバシーに注目する技術に関心を持つ人が増えるにつれて、インターネット上のプライバシー問題は改善の機会があると信じています。

To Be Continued…

では、なぜ私がW3C DIDsシリーズの記事でSemaphoreを紹介するのでしょうか？主な理由は、昨年下半期に行ったプロジェクトで、内政部のモバイル自然人憑証、W3C DIDs、そしてSemaphoreゼロ知識証明フレームワークを融合させ、これらの異なる技術を統合する可能性を実験的に検証し、同時にさまざまな長所と短所を評価したためです。

これは実際に、W3C DIDsとVCとSemaphoreのプライバシー保護を重ね合わせ、プライバシー保護をさらに最先端で未知の境界へと押し進めるものであり、このような状態でこそ、これらの技術のさまざまな側面をより容易に観察できます。

しかし、W3C DIDs/VC、Semaphore、さらには分散型身元識別も、一度にすべてを明確に説明することは非常に困難であるため、このシリーズの記事ですべての知識を展開することにしました。次の記事はシリーズの最後の記事となります。今月中に書き上げて公開できる機会があることを願っています。ご期待ください！

W3C DIDs:権力構造を解体するデジタルアイデンティティ標準

Mon, 01 Jan 2024 00:00:00 GMT

前回の関連記事『Facebook による理不尽なアカウント凍結から見るデジタルアイデンティティの問題と DID ソリューション』では、私が Facebook に理不尽に凍結された悲劇からデジタルアイデンティティの現状を再検討し、この現状を打破しようとする標準である W3C DIDs について簡単に触れました。今回は、W3C DIDs のメカニズムがどのように現状を変えるのか、より深く掘り下げて探っていきたいと思います。

前回の記事をまだ読んでいない読者は、まず振り返ってみてください 😎

現状

私の観点から見ると、現在のデジタルアイデンティティサービスにはいくつかの問題があります:

自律性

現在のデジタルアイデンティティはユーザーが所有しているのではなく、大企業が所有しており、企業がそのデジタルアイデンティティの使用を許可しているに過ぎません。私の Facebook アカウントが私の同意なく永久削除されたケースのように。

プライバシー

アイデンティティプロバイダー(つまり Google や Facebook などの企業)は、ユーザーのログイン行動を追跡でき、ユーザーのデジタルフットプリントは彼らの収益ツールとなっています。ユーザーのデジタルフットプリントを通じて広告の糧となり、豊富な利益を得ることができます。企業が所有する Google 検索エンジンや Facebook ソーシャルネットワークなどの他のサービスと、ウェブサイトに埋め込まれた Facebook コメント機能を組み合わせれば、ユーザーの姿を十分に組み立て、あなたが好む広告を提供し、さらには騙されやすい詐欺広告まで提供することができます。

しかし、DIDs はどのようにしてこれらの問題を解決するのでしょうか?まず、DIDs についてさらに詳しく理解しましょう。

W3C DIDs

W3C 分散型識別子(Decentralized Identifiers, DIDs)は、分散型アイデンティティ識別の標準であり、ユーザーは暗号学に基づくデジタルアイデンティティを使用して本人確認を行うことができます。実際に W3C DIDs を使用する場合、しばしば別の標準である W3C 検証可能クレデンシャル(Verifiable Credentials, VCs)と併用する必要があります。2つの標準はそれぞれ異なる機能を担当しています:

DIDs 標準:DID アイデンティティ識別をどのように検証するか
VCs 標準:ある DID が別の DID の主張を裏書きする際に発行される証明書

例えば、Alice がゲーム購入プラットフォーム(このプラットフォームを Stream と呼びましょう)で、ゲーム開発会社 “SE” が開発したゲーム『ファースト・ファンタジー』を購入する場合、Stream は Alice にゲーム購入証明を発行します。

この状況下で、プラットフォームとしての Stream は DID アイデンティティ識別を持ち、Alice も個人として DID アイデンティティ識別を持ちます。Stream は Alice がゲームを購入する前に、まず Alice の DID 識別から検証方法の情報を見つけ、この Alice DID 識別を検証します。DID 標準はこれらの検証情報の仕様を定めています。

Alice が DID 検証を通過してゲームを購入すると、Stream は Alice に VC 標準形式のゲーム購入証明を発行します。その中で Stream の DID が発行者(Issuer)として、Alice が Stream でゲーム『ファースト・ファンタジー』を購入したことを証明します。これは特定の主張を裏書きするために生成される証明書です。この証明書を受け取ったシステムは、その中の情報に基づいて VC に記載された情報が正確であるかを検証できます。これが VC 標準が提供する機能です。

DID 識別は次のような形式です:

DID 識別は3つのフィールドで構成され、コロンでフィールドを区切ります。最初のフィールドは固定の文字列 did、2番目のフィールドは DID Method です。暗号学に基づくデジタルアイデンティティには非常に多くの異なる種類とプラットフォームがあり、ブロックチェーンプラットフォーム、非ブロックチェーンプラットフォーム、ユーザーが自分のウェブサイトに配置した公開鍵情報、さらにはローカルで生成された公開鍵もサポートされています。これらの異なる DID タイプのアクセス方法を DID Method と呼び、2番目のフィールドはこの DID 識別がどの DID Method を使用しているかを示します。3番目のフィールドは特定の DID Method に対する識別文字列です。

例えば、次の DID 識別:did:ethr:0xb9c5714089478a327f09197987f16f9e5d936e8a が意味するのは:

did:これは DID 識別である
ethr:この DID 識別が採用する識別方式は ethr という DID Method
0xb9c5...6e8a:ユーザーがこの DID Method でこの文字列を使用して特定のアイデンティティ識別を表す(身分証番号のようなもの)

この DID 識別文字列を適切なライブラリで解析すると、この DID とどのように相互作用するか、例えばアイデンティティの検証方法や証明書の検証方法などの相互作用情報が得られます。これらの相互作用情報は JSON ファイルであり、DID Document と呼ばれます。

ここでいくつかの異なる DID Method を紹介します:

did:key:ユーザーが DID 識別文字列内に直接公開鍵を提供し、公開鍵情報を他の場所に配置しない
did:web:ユーザーが公開鍵情報を自分のウェブサイトに配置
did:ethr:ユーザーが Ethereum ブロックチェーン上の自分のアカウントアドレスを DID 識別として指定

上記3つ以外にも DID Method は非常に多く存在します。より多くの種類については DID Specification Registries を参照してください。

did:key

did:key は、DID 識別の文字列自体に公開鍵情報が含まれているため、ブロックチェーンや他の公開鍵を保存する場所が不要です。例えば、DID 識別 did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK の3番目の部分 z6Mk...2doK はあるアルゴリズムの公開鍵であり、この情報だけでこの DID 識別を検証するのに十分です。どの暗号アルゴリズムかを判断するには、3番目のフィールドの先頭から判断できます。例えば:

z6Mk: Ed25519 アルゴリズム
zQ3s: Secp256k1 アルゴリズム
zDn: P-256 アルゴリズム

したがって、上記の例 z6Mk...2doK は Ed25519 アルゴリズムを採用してメッセージを検証する必要があることが識別できます。

did:key の利点は非常にシンプルで、ユーザーが自分で管理できることです。アプリとしてパッケージ化すれば、TouchID などの生体認証デバイスを使用して秘密鍵を安全に保存することもでき、非常に便利な選択肢です。欠点は柔軟性がやや低いことです。例えば、複数の異なるデバイス(スマートフォン、コンピュータなど)で1つの DID アイデンティティを管理したい場合、安全な管理方法がありません。

もう1つの欠点は、did:key の現在の形式が WebAuthn の形式をサポートしていないため、ウェブページ上で直接生体認証デバイスを使用して did:key を管理できず、モバイルアプリとしてパッケージ化する必要があることです。

2024-02-05 更新:最近 ceramicnetwork/js-did/key-webauthn を見つけました。WebAuthn を使用して did:key を生成・検証できる可能性があるようです。

did:web

did:web は、ユーザーが特定の URL に JSON をアップロードすることで DID 相互作用情報を提供する方法です。例えば、DID 識別 did:web:mattr.global は実際には URL https://mattr.global/.well-known/did.json から DID 識別情報を取得します。この DID の所有者は、ウェブサイトに配置されたこの JSON ファイルを変更することで、アイデンティティ検証の要件を調整できます。例えば、複数のデバイスでそれぞれ異なる暗号鍵を持つことで、スマートフォン、コンピュータ、タブレット上でログインできるようにしたり、定期的に鍵を更新してセキュリティを維持したりすることもできます。

did:web の利点も非常にシンプルで、更新も非常に便利です。おそらく、人々は自分がその URL を所有していると感じるため、かなり安全だと感じるでしょう。欠点は、一般の人にとっては特に便利とは言えないことです。簡単な方法としては Github pages にファイルをアップロードすることが考えられますが、エンジニアにとっては簡単でも、一般ユーザーにとってはやや難易度が高いでしょう。

しかし、分散化の観点から見ると、did:web にはいくつかの欠点があります。例えば、Github Pages に配置している場合、あなたと Github との間に利益相反が生じ、公式があなたのウェブサイトを削除すると、あなたのデジタルアイデンティティも奪われてしまいます。ドメイン名も登録しても期間制限があり、同様にドメイン業者と利益相反が生じてドメインが無効になる可能性もあります。

もちろん、ほとんどの人の観点から見れば、この方法はすでに十分な自律性を持っています。しかし、心配な場合は、やや柔軟性のない did:key を使用するか、次のソリューション did:ethr を検討してください。

did:ethr

did:ethr は、DID 識別の相互作用情報を Ethereum または互換性のあるブロックチェーン上に配置する DID Method です。例えば、DID 識別 did:ethr:0xf3beac30c498d9e26865f34fcaa57dbb935b0d74 では、3番目の部分がアカウントアドレスであり、ユーザーはこのアカウントを制御する秘密鍵を使用してこの DID 識別を検証できます。デフォルトの検証方法はメッセージに対する署名であり、これは Ethereum ブロックチェーンユーザーが頻繁に行う操作で、直感的です。

すぐに使用できるだけでなく、スマートコントラクトを通じてこの DID の詳細設定も可能で、複数デバイス/秘密鍵で同じ DID 識別を管理したり、鍵の更新や交換などの高度な機能も実現できます。

did:ethr の利点は、did:web と同様に DID 識別を調整するためのより多くのオプションがあり、同時に十分に分散化されており、対応する秘密鍵を所有していれば DID 識別を完全に制御できることが保証されています。クラウドサーバープロバイダーやドメイン業者などの仲介者がユーザーと利益相反を起こしてデジタルアイデンティティを奪うことはありません。

しかし、欠点も明白です。did:ethr はブロックチェーン技術を採用しているため、ブロックチェーンに触れたことのないユーザーにとってはハードルが高く、使いにくいでしょう。

Verifiable Data (VC)

VC は DID Document と同様に JSON ファイルであり、前述のように VC はある DID が別の DID に発行する証明書で、特定の主張を裏書きするものです。同じくゲーム購入プラットフォーム Stream の例で見ると、Stream の DID は did:web:streamgame.com である可能性があり、Alice が自分の Ethereum ブロックチェーンアカウントを自分のアイデンティティとして選択する場合、DID は did:ethr:0xf3beac30c498d9e26865f34fcaa57dbb935b0d74 のようになります。

ここで、VC 内の発行者と授与者は異なる DID Method を使用できることも観察できます。したがって、公開鍵をウェブサイトに保存している発行者も、Ethereum アカウントアドレスを DID 識別として使用しているユーザーに VC 証明書を発行できます。

Alice がゲームを購入すると、Stream のシステムは Alice に VC ゲーム購入証明書を発行します。例は次のとおりです:

{
  "@context": ["https://www.w3.org/2018/credentials/v1"],
  "issuer": {
    "id": "did:web:streamgame.com"
  },
  "credentialSubject": {
    "id": "did:ethr:0xf3beac30c498d9e26865f34fcaa57dbb935b0d74",
    "purchaseId": "123456789",
    "gameTitle": "First Fantasy",
    "purchaseDate": "2023-12-31T15:00:00Z",
    "paymentAmount": 59.99,
    "currency": "USD",
    "platform": "PC"
  },
  "type": ["VerifiableCredential"],
  "issuanceDate": "2023-10-30T07:57:06.000Z",
  "proof": {
    "type": "JwtProof2020",
    "jwt": "eyJhbGci...2rzP0K5wow"
  }
}

この例では、発行者(Issuer)が did:web:streamgame.com であり、ゲームを購入した人は Alice の DID did:ethr:0xf3beac30c498d9e26865f34fcaa57dbb935b0d74 であり、credentialSubject フィールドにゲーム購入情報があることが記述されています。

ここで重要なのは、proof フィールド内に発行者によるこの VC の署名情報があることです。このファイルを入手した誰もが、このファイルが確実に Steam によって署名・発行されたものであるかを検証できます。Alice はこの証明書を取得した後、他の人や企業に提示してこのゲームを所有していることを証明できます。

例えば、彼女が購入したゲーム『ファースト・ファンタジー』のゲーム会社 “SE” が次世代のゲーム『ミドル・ファンタジー』を発売し、新バージョンは Stream では販売されず、“SE” の公式ウェブサイトでデジタル版を購入できるようになりました。しかし、購入者は『ファースト・ファンタジー』の購入証明を通じて『ミドル・ファンタジー』を40%オフで購入できます。

また、credentialSubject の id 属性に Alice の DID 識別が記録されているため、“SE” 公式ウェブサイトは VC に記録された購入者であることを確認する際、ユーザーの DID の署名を要求することもでき、その人が盗まれた購入証明ではなく、この購入証明の購入者本人であることを確認できます。

次に、同じ例を使用して、現行のアイデンティティ検証メカニズムと DID アイデンティティ検証メカニズムを採用した場合の違いを検討します。

例:現行のアイデンティティ検証と DID の違い

上記の例では、Alice がゲーム購入プラットフォーム Stream から『ファースト・ファンタジー』を購入し、新バージョンのゲーム『ミドル・ファンタジー』は “SE” 公式サイトでデジタル版を販売しており、以前 Stream で前バージョン『ファースト・ファンタジー』を購入していれば40%オフで『ミドル・ファンタジー』を購入できます。

現行のアイデンティティ検証メカニズム

現行のアイデンティティ検証メカニズムでは、Stream ゲーム購入プラットフォームは Stream プラットフォームへのログイン機能を提供し、通常は OpenID Connect (OIDC) のような標準を採用してこの機能を提供します。ゲーム公式ウェブサイトで OIDC を通じて Stream に接続した後、Stream の API を通じてユーザーの購入情報を取得します。

次に、この方法が自律性とプライバシーの面でどのような問題があるかを検討しましょう:

自律性

Stream が古すぎるという理由で『ファースト・ファンタジー』を削除した場合、または Alice と Stream の間に利益相反が生じた場合(例えば、Alice が競合プラットフォーム Epico の広告を手伝った)、Stream が Alice が「プラットフォーム規約に違反した」と主張してアカウントを凍結した場合、“SE” 公式ウェブサイトは他の方法で Stream 上の Alice のデータを取得することはできません。

この状況は、Facebook が完全に理由なく私のアカウントを永久凍結したのと同じです。私は Facebook 上のデジタルアイデンティティを本当に所有しているわけではありません。

プライバシー

ゲーム公式ウェブサイトが『ミドル・ファンタジー』の割引販売のために Stream API を通じてログインし、購入記録を照会する必要がある場合、Stream は Alice が “SE” 公式ウェブサイトショップでのデジタルフットプリントを知ることになります。Stream もユーザーのデジタルフットプリントで収益を上げるゲームプラットフォームである場合(例えば、ゲーム広告を提供している)、ユーザーのデジタルフットプリントを記録する強い動機があります。

次に、W3C DIDs を採用した場合がどのような状況になるかを見てみましょう。

W3C DIDs アイデンティティ検証メカニズム

W3C DIDs を使用して購入証明メカニズムを実装する場合、Alice がゲーム『ファースト・ファンタジー』を購入すると、Alice の DID 識別に基づいて Verifiable Credential 形式のゲーム購入証明が Alice に発行されます。この購入証明には Stream 発行者の署名、購入者情報、ゲーム情報が含まれます。

Alice が “SE” 公式ゲームプラットフォームから新バージョンの『ミドル・ファンタジー』を購入する際、Stream プラットフォームでの購入資格を確認する必要がある場合、そのゲーム購入証明書 VC を “SE” 公式ウェブサイトに提供するだけで済みます。この時、“SE” 公式ウェブサイトはその証明書が Stream によって発行されたものか、正しいゲーム購入証明書か、そして購入者の署名検証を通じて Alice が購入時に使用した特定の DID 識別を所有しているかを検証します。

VC 形式の購入証明を検証した後、“SE” ゲーム公式ウェブサイトは Alice に割引を提供できます。次に、同様に自律性とプライバシーを検討してみましょう。

自律性

Stream が VC 購入証明書を Alice に提供した後、その上には Stream 発行者の署名が付いており、この署名は否認できません。Stream 発行者が確実に署名したことを証明します。

W3C DIDs 標準には実際に取り消しメカニズムが用意されていますが、この取り消しメカニズムは取り消しリストを通じて発行者がこの証明書を取り消し状態としてマークするだけで、以前 VC に付けられた署名は依然として否認できません。

Stream が Alice の購入証明が取り消されたとマークしても、以前 Alice が保存していた購入情報証明書は、彼女が以前 Stream でこのゲームを購入したことを証明できます。なぜなら、必要な情報はすべて証明書の中にあるからです。取り消しメカニズムはこの証明書を取り消し済みとマークしますが、Stream 発行者が以前この証明書に署名したことを否認することはできないため、証明書の発行者署名は依然として有効であり、ただ取り消し済みのマークが追加されるだけです。

これにより、『ミドル・ファンタジー』を販売する “SE” 公式ウェブサイトは、このような証明書を受け入れるかどうかを自分で決定でき、権力がすべて発行者に集中することはありません。

プライバシー

Alice が証明書をゲーム公式プラットフォームに提供する際、Stream が発行者の公開鍵情報をウェブサイトに配置することを選択した場合、せいぜい誰かが公開鍵情報をダウンロードしたことがわかる程度で、どのユーザーがどのゲームを検証しようとしているかはわかりません。Ethereum ブロックチェーンに配置した場合、Stream は誰かが公開鍵情報をダウンロードしたことすら知りません。プライバシー保護の面では、現行の実装方法よりも優れています。

これら2つの特性における従来の検証メカニズムと DID 検証メカニズムの違いは次のとおりです:

特性	従来のアイデンティティ検証メカニズム	W3C DIDs アイデンティティ検証メカニズム
自律性	プラットフォームはユーザーの証明書やアイデンティティを取り消し、すべてのデータアクセスを拒否する権限を持つ	プラットフォームは証明書を取り消し済みとマークできるが、以前署名した証明書を否認することはできない
プライバシー	API を通じてログインやデータ照会を行う際、プラットフォームはユーザーのデジタルフットプリントを取得できる	プラットフォームはログイン行動を通じてユーザーのデジタルフットプリントを追跡できない

結論:プライバシーと自律性は保証されたが、まだ何が足りない?

上述のように、W3C DIDs および Verifiable Credentials 標準は確実にユーザーのアイデンティティ検証における自律性とプライバシーを向上させます。このメカニズムがこれほど優れているのであれば、今すぐ DID を導入すべきであり、私たちは何を待っているのでしょうか?

DIDs はまだ形成されて間もない標準プロトコルであり、実際にはまだ多くの不足している部分があります。まず、DID と VC をより良くサポートするには、さまざまな VC 証明書を収納できるアプリが必要であり、使用する必要がある時にこのアプリを通じて今回使用する証明書を選択できるようにする必要があります。このアプリはユーザーの秘密鍵を管理する機能も必要です。このアプリの本質は Apple Wallet や Google Wallet のようなチケットや会員カードを収納するウォレットに非常に似ていますが、内部または外部の秘密鍵を管理する機能の実装も必要になります。

現実には、これを行うための成熟した使いやすいアプリはありません。さらに、DID はまだ初期段階にあるため、VC Wallet を先に用意するべきか、DID を先にサポートするべきかという、鶏が先か卵が先かという問題になります。

次の問題は動機です。上記の説明のように、DID を採用すると、アイデンティティプロバイダーや証明書発行者の権力は大幅に縮小され、ユーザーのデジタルフットプリントを追跡することも困難になります。ここで立場を変えて考えてみましょう。Google や Facebook が新しいアイデンティティ検証プロトコルを実装すると広告の精度が大幅に低下し、主要な収益源である利益が減少し、同時にユーザーに対するさらなる制御権を失うとしたら、彼らが DIDs に切り替える動機は何でしょうか?

より良い切り口は規制の観点からかもしれません。例えば、EU のような監督機関が巨大企業にデジタル世界に対する支配力を縮小するよう規制したり、政府が公式証明書(身分証や運転免許証など)について DID 標準を率先して採用したりすることが、より良いアプローチだと考えます。

振り返ってみると、DIDs はまだ非常に初期段階にあり、直面する欠点は実に多いです。しかし、逆に見れば希望に満ちた場所でもあります。この標準は、現在の巨大企業がデジタル世界に対して持つ巨大な支配力について再考し、より自律的でプライバシーに配慮した青写真を描いており、標準を通じて本来ユーザーに属すべき権力を取り戻す機会があるかどうかを考えさせてくれます。

もちろん、未来に対する想像力はこれだけに留まる必要はありません。さらに一歩進めて考えてみましょう:もっと良いプライバシーが欲しい場合、現在どのようなソリューションが達成できるでしょうか?例えば、ユーザーが以前 Stream で『ファースト・ファンタジー』を購入したかどうかを検証する際、自分の DID 識別すら開示せずに、ユーザーが確実にそのゲームを購入したことを証明できないでしょうか?

次の記事では、ゼロ知識証明のフレームワークである Semaphore がどのようにさらに進んだプライバシーアプリケーションを実現するかを解説します。次回をお楽しみに!

補足情報

did:web における鍵の無痕跡交換の問題

Luoh Ren-Shan が Facebook のコメントで、発行者 Stream が did:web を DID として採用した場合、発行者は無痕跡で自分の鍵情報を変更して、Alice の手元の証明書を無効にできると指摘しています。

これは確かに問題ですが、このように鍵情報を更新すると、Stream が元の鍵で発行した他の証明書もすべて無効になり、Alice の証明書だけに限定することはできません。これは Stream 発行者に対する信頼危機を生じさせることになり、did:web を使用する発行者としては、良し悪しのトレードオフでそうするかどうかを考慮する必要があります。もちろん、大きな問題が発生した場合、発行者はこの手段を使って厄介な問題を積極的に処理する可能性がありますが、従来の方法で簡単に結果を操作できるのと比較すれば、did:web を使用する方がまだ信頼に値しますが、完璧ではありません。

振り返って、did:ethr を使用している場合、DID 所有者が鍵情報を更新すると履歴記録が残り、パラメータクエリを通じて以前のバージョンの DID ドキュメントを取得できるため、did:web よりもさらに信頼できます。

Yuren's Blog - 技術

OpenClawが開いた扉

Claude Codeに受け入れテストを自動実行させる

BDD + TDD

AIにコードを書いてもらったら、理解してもらえない？

従来のソフトウェア開発の議論

ルールで方向性を定義する

仕様（Spec）を分割し、段階的に進む

仕様には受け入れ条件が必要

これまでのところ…

Claude Desktop内で直接トークン取引を行う

あとがき

Perplexity Cometブラウザのリリース前に

ChatGPTは好奇心の反射と拡張である

Footnotes

tw-did 補足情報

概念実証：プライバシー優先の台湾住民デジタルアイデンティティ

モバイル自然人憑証

自律性

プライバシー性

TW-DID実験プロジェクト

W3C DIDs/VC統合

自律性

プライバシー性

Semaphore統合

デモ動画

レビューと考察

試作品は未来のシナリオの想像を提供するか

デジタルアイデンティティの自律性とプライバシー性

開発キット

Walletの欠如

交換プロトコルの欠如

Semaphoreはプライバシー性を向上させるが、実装の詳細には改善が必要

結論

Semaphore：プライバシーを強化するアイデンティティソリューション

例のシナリオ

紙のチケット

デジタルチケット

Semaphore認証

Semaphoreを使用する理由とシナリオ

オンラインでのアルコール購入

内部告発者プラットフォーム

薬物または困窮者支援

意見調査

結論

To Be Continued…

W3C DIDs:権力構造を解体するデジタルアイデンティティ標準

現状

自律性

プライバシー

W3C DIDs

did:key

did:web

did:ethr

Verifiable Data (VC)

例:現行のアイデンティティ検証と DID の違い

現行のアイデンティティ検証メカニズム

自律性

プライバシー

W3C DIDs アイデンティティ検証メカニズム

自律性

プライバシー

結論:プライバシーと自律性は保証されたが、まだ何が足りない?

補足情報

did:web における鍵の無痕跡交換の問題