グラレコ
はじめに
Developer Summit 2026 Summer（デブサミ2026夏）の2日目、2026年7月17日に参加し、3つのセッションを聴講してきました。前回の1日目レポートでは「確率的な生成を決定論で受け止める」「人間に判断を残す」「コンテキストが成否を分ける」という共通テーマが浮かび上がりましたが、2日目はその続きを別の角度から掘り下げるような一日になりました。
この記事では、聴講した3セッション——ナレッジグラフでAIエージェントを「チーム
メイト」にする話（DevRev）、ドメインエキスパート×PdMが顧客の声の「先」を見る話（Works Human Intelligence）、Verifiable Credentials に産学連携で挑む話（伊藤忠テクノソリューションズ×慶應義塾大学）——を、講演の流れに沿ってできるだけ細かく整理します。テーマはAIエージェント・プロダクトマネジメント・デジタルアイデンティティとバラバラに見えて、終わってみると「記憶」「本質」「信頼」という言葉できれいにつながっていました。最後の「共通テーマ」まで読んでいただけると、1日目とあわせて2026年夏の現在地が立体的に見えてくると思います。
💡 本記事は筆者個人の聴講メモに基づくレポートです。講演の全内容を網羅・正確に再現するものではなく、講演中の数値はスライドからのメモで独自検証はしていません。文責はすべて筆者にあります。
2日目の全体像 🗓️
聴講したセッションのタイムテーブルです。
| 時間 | セッション | 登壇者 |
|---|---|---|
| 12:40–13:10 | AIエージェントは「チームメイト」になれるか - 開発・サポート・ビジネスをつなぐ新しい働き方 | 鈴木 孝規氏（DevRev Japan） |
| 13:25–13:55 | エンジニアに、お客様の声の「先」は見えているか？ ～ドメインエキスパート×PdMが要望の裏の「真の課題」を解き明かす～ | 杉田 生楽氏・長井 弘明氏（Works Human Intelligence） |
| 14:55–15:25 | インターネットへの「信頼」の実装 ―Verifiable Credentials に産学連携で挑む話 | 貞弘 崇行氏・藤田 和成氏（伊藤忠テクノソリューションズ）、橋本 晃太朗氏・伊藤 有汰氏（慶應義塾大学） |
先に2日目の見取り図を言ってしまうと、「AIに渡すべきは賢いモデルではなく記憶」「人間の仕事は声の先にある本質を見極めること」「信頼は精神論ではなく実装できる」の3本柱でした。順番に見ていきます。
セッション1：AIエージェントは「チームメイト」になれるか 🤝
（鈴木 孝規氏／DevRev Japan）
自称「ナレッジグラフおじさん」こと鈴木氏によるセッションです。Zenn Book『LLMをもっと賢くするナレッジグラフ実践入門』の著者で、みんなで Claude Code を使って一緒に開発する体験をつくる OSS「cc-room」の開発者でもあります。DevRev は開発（Dev）と顧客（Rev）を一つのナレッジグラフでつなぐAIプラットフォームで、2020年に米国パロアルトで創業（Nutanix 共同創業者が設立）、従業員750名・世界8拠点、2025年9月に日本法人設立、特許30件以上という会社です。
テーマの一文が強烈でした。「RAGを組み、デモでは完璧に動いた。それでも本番で、AIは自信を持って間違える」。多くのチームが直面するこの課題を一段深いところから捉え直す、という構成です。
ある1件の問い合わせの物語：AIは自信を持って間違える
講演はデモシナリオ（架空のSaaS企業への問い合わせ）から始まります。「TKT-421：ログインできません。朝から全社員が入れない。至急お願いします」——エーテック製作所からの緊急チケットです。AIエージェントに「原因と影響範囲を調査して」と頼むと、MCP経由で4つのツールを直列に呼び出します。
この図のポイントは、個々のツール呼び出しは全部「成功」しているのに、答えが間違う点です。検索は「今あるもの」しか返さない（本当の原因はまだ誰にも起票されていない）。システム間に共通キーがない（類似度で「たぶんこっち」と推測するしかない）。類似度では「現行版」を選べない。これはモデルの性能の問題ではなく、速いモデルでも賢いモデルでも解決しない。AIに渡している「記憶」の問題だ、というのが最初の主張です。
もう一つ重要な整理が、「読む」と「アクション」の非対称性です。質問して回答をもらう「読む」は精度が低くても対話でカバーできますが、データを書き換える・送信する「アクション」は一度実行したら取り返しがつきません（別会社への障害情報の誤送信、顧客DBの上書き破壊など、実行された時点で事故です）。だからAIにはドラフト作成までしか任せられず、最終アクションは必ず人間が確認する。結果、AIがどれだけ速くても人間がボトルネックになる。本番で戦力にならない理由は「安心して任せられない」から、という診断でした。
詳しい人の頭の中＝ナレッジグラフ
同じ問い合わせを、社内で最も状況を把握しているサポートマネージャー（元開発部で認証システム担当）に聞くと、10秒でこう答えられます。「認証まわりのログイン障害。先週の障害はログイン有効期限の設定ミスで直っているので今回は別原因。開発の中村さんに調査依頼を。エーテック製作所は契約更新が近いので営業にも共有を」。
この人の頭の中にあるのは、点と点のつながりです。TKT-421—エーテック製作所—商談9,000万円—担当営業。TKT-421—ログイン機能—ISS-9（先週Close・別原因）—ISS-12（今回の本当の原因）—手順書v2（現行公開版）。線をたどると、推測だった判断が根拠を持って確定します（別会社と確定、先週のISS-9は時系列で無関係、今回は新Issueが必要、現行手順書はv2、商談9,000万円が紐づくので営業へ連絡……）。バラバラだった点が線でつながった瞬間、AIは推測ではなく「たどって」答えられる。ナレッジグラフとは、この「詳しい人の頭の中」を、あらかじめ定義された関係（オントロジー）に沿ってAIに渡せる形にした層であり、開発チケット・カスタマーサポート・プロダクトフィードバックの3つを統合するものだ、という定義です。
ナレッジグラフが持つ3つの鍵：関係・時系列・権限
ナレッジグラフの効能は3つの鍵に整理されました。
-
鍵①関係: つながりをたどれば影響範囲まで一度でわかる。
graph.traverse(start="TKT-421", depth=3)の1回のクエリ（41ms）で、原因（ISS-12、恒久修正v2.4.2を7/8リリース予定）、影響顧客3社（名寄せ済み）、止まっている商談9,000万円、対応手順（手順書v2、先に認証サーバ再起動が必要）まで取得。「推測で止まるか、根拠を持って答えるか」 -
鍵②時系列: 「その時」しか見ないAIにはできない判断ができる。
timeline(node="ログイン機能", window="30d")で、6/25 ISS-9修正Close → 6/29 22:00 v2.4リリース → 6/30 09:15 認証エラー急増 → 6/30 10:20 ISS-12起票 → 7/7 修正80%、という前後関係が見える。「似ているが別原因」は前後関係を持っているから言える - 鍵③権限: 誰が聞くかで答えが変わる。同じ「TKT-421の状況を教えて」でも、営業には商談9,000万円停止中・修正7/8予定・顧客への共有推奨（技術詳細は要約のみ）、サポートには原因ISS-12・対応手順v2（商談金額は含まれない）。権限外のデータはそもそも回答に含まれないから、誰にでも安心して使わせられる
これをシステムにしたのが4層アーキテクチャです。
この図のポイントは、LLMの下に「記憶」の層が明示的に挟まっている点です。キーフレーズは「LLMに検索させない。記憶が先、LLMは判断だけ。」でした。
あの朝のリプレイ：人間がやったことは承認2回
もし最初から記憶を持ったエージェントがいたら、という「あの朝のリプレイ」も具体的でした。①9:02の着弾と同時にエージェント起動、過去Issueとの時系列比較で「別事象の可能性が高い」と判定 → ②デプロイ履歴×ログ相関で原因リリースを特定 → ③v2.4にはセキュリティ修正（セッション固定化攻撃対策）が同梱されているためロールバック不可・前方修正が必要という「動かない判断」を理由付きで記録 → ④ISS-12自動起票・担当アサイン・Slackチャンネル自動作成（人間の判断=この方針でGoか、承認①）→ ⑤affectsリンクから影響3社を特定し営業・SEに自動通知、顧客への一次回答ドラフト生成（人間の判断=顧客に出す前の最終確認、承認②）→ ⑥修正デプロイを検知して自動クローズ、Jira/Zendesk/Salesforce横断更新、営業に「商談再開可」シグナル。
人間がやったことは、承認2回。1週間後に「先週のログイン障害あれどうなった?」と聞けばグラフをたどって顛末を答え、障害中に原因と修正予定を事前共有できたため大きなクレームにならず、同じログイン機能を使う他2社にも問い合わせが来る前に説明でき、止まっていた9,000万円の商談は修正完了の連絡で再開——「関係を理解したAIは、聞かれる前に動ける」。
さらに「データの複利」という考え方も紹介されました。今回人間が下した判断（前方修正で行く）が記憶になり、3ヶ月後の類似障害でエージェントが「前回の判断理由はこれです。今回はどうしますか？」と提示してくる。やがて誰かの失敗を別の人が繰り返さなくなる。記憶があるとツール間の「ズレ」（PRはQAまで進んでいるのにJiraだけ未更新）も検知して自動同期できる。「memory.md は自分の経験からしか学ばない。組織の記憶は、全員の経験から学ぶ。」という一文は、Claude Code のメモリ機能を使っている身として刺さるものがありました。
実証：事例・実測・ベンチマーク
裏付けの数字も豊富でした。
| 実証 | 内容（講演スライドより） |
|---|---|
| BILL（米国FinTech、GDPの約1%相当の取引を処理） | 年間140万件の問い合わせの70%をAIが人手を介さず解決し、年間500万ドルのコスト削減。システムはリプレースせず Salesforce Service Cloud と請求システムをつないだだけ。最初のセグメントは契約から約7週間で本番稼働、全セグメント100%展開まで15週間 |
| 実測比較（同じ Claude Sonnet 4.6・同じ質問） | Claude単体（Skills/MCPで毎回データ取得）は抽象的な箇条書きで根拠チケットなし。事前統合された記憶を読む Computer は「ゴールド会員に不要な手荷物料金が請求されている」など具体的事象を出典つきで提示。正確さ1回で確定・トークン95%減・5.5倍速 |
| Enterprise-Bench（第三者機関 Laude Institute と共同作成・全公開） | 同一モデル（Claude Opus）・同一データで、変えたのはデータの取り方だけ。14タスク×10試行×5スケール=700観測点。精度は記憶ベース92〜97%で一定、MCPは57%。信頼性 pass@5 は記憶100%、MCP多段は2〜7/10。データ256倍時のコストは記憶が横ばい、MCPは+37% |
そして決定打が「モデルを最新にしても+1pt、正しい記憶を渡すと+18pt。ボトルネックはモデルではなく、記憶。」です。1日目の黒田氏の「成否を分けたのはモデルの性能ではなくコンテキストの構造」と、独立にぴったり重なる結論でした。
最後は製品の話も率直で、ナレッジグラフ・時系列・権限フィルタといった基本構造は OSS でも構築できる、と明言したうえで、製品としての違いは特許4件（異種システムのイベント統合・自動相関／変更のインテリジェント通知／3層スケーラブルなベクトルDB／LLM+ライブ文脈での応答生成）と、200名超のエンジニアが2年以上・1.5億ドル以上をかけて作ってきた「最後の、地味な2割」（4システムの複合マッチによる自動名寄せ、プレビルトオントロジー、検索もSQLも漏れなく制御する全エンジンへの権限注入）だと。小規模チームや単一ツールで完結する範囲なら自作の方が速い場合もある、自作と製品導入は要件次第、というフェアな締めでした。まとめの一文は「AIエージェントは、チームメイトになれる。条件は、関係・時系列・権限という『記憶』を渡すこと。Work Softer.」。
セッション2：エンジニアに、お客様の声の「先」は見えているか？ 🔍
（杉田 生楽氏・長井 弘明氏／Works Human Intelligence）
統合人事システム「COMPANY」を手がける Works Human Intelligence（WHI）から、ドメインエキスパートと PdM の2名が登壇したセッションです。長井氏は2015年にWHIの前身会社へ入社後、DevOps 組織での製品開発、導入コンサルタント・導入手法企画・保守コンサルタントなどの顧客対応部門を経て、2022年に製品と業務ドメインの有識者として製品開発部門へ再joinし、2026年から COMPANY Web Service の Domain Expert として正式に従事。金融（政府系金融機関・地方銀行）、製造・建設（自動車・食品・総合空調設備メーカー）、生活協同組合などを担当してきたそうです。杉田氏も2015年入社で、開発プロセスのガバナンス構築・QE → 開発サイクル全体 → 共通機能開発責任者 → 2026年から PdM という経歴。おふたりとも「1つの製品を軸に様々な職種を経験してきた」ことが今の役割の土台になっています。
COMPANY のスケールと、強みの裏返し
前提となる「COMPANY」の規模がまず圧巻です。約1,200法人グループが利用し、約570万人の人事データを管理、ソースコードは数千万行規模。ERP市場・人事/給与業務分野でシェアNo.1（ITR調べ）で、1996年の誕生以来、人事業務の全領域を1ソースでカバーし、個社カスタマイズではなく標準機能で全てを賄う方針で複雑な日本の人事制度に適応してきました。
ただ、強みには裏返しの課題があります。開発側は、機能の積層でコードが肥大化・複雑化し、変更の影響範囲が見えにくくリリースに慎重さが必要（対応方向は「リリースをより早く安定的に」「AIを活かすためのコード基盤の整備」）。保守側は、使い方が豊富なゆえに最適な利用提案に熟考が必要で、問い合わせ・機能要望が多くすべてに応えきれない。開発者は「製品が抱える豊富なノウハウ」「たくさんのお客様の声」「市場の変化」のすべてと向き合う時間がとれず、疲弊し、整理されないまま開発して場当たり的なアウトプットに陥る——という現状の課題が率直に語られました。そのうえで「実はそうじゃない！おもしろい…!! というのを伝えたい」がこのセッションのメッセージです。
Domain Expert という役割：2名で80サブシステムを支える
役割の定義はこうです。Domain Expert は、豊富なノウハウを抱えた「製品」と、それと向き合って培われた圧倒的な「ドメイン知識」から、人事業務の標準と正解を作っていくフェーズの先頭に立つ。Product Manager は、お客様の要望に真摯に向き合いながら、製品進化に必要な本質を見極め、選択と集中の戦略を立てる。
体制の数字が印象的でした。長井氏の担当する COMPANY Web Service（申請ワークフロー・情報照会。個人情報申請・マイナンバー申請・経費精算・年末調整申告・給与情報照会・評価・発令申請など）の開発組織は、15ドメイン領域・80サブシステム・7グループ。これに対して Domain Expert は2名で、各サブシステム・グループに Cross-Functional なサポートを行います。ミッションは、①BugFix/Function を問わずドメイン知識が必要な案件へのレビュー参加、②Domain Expert 自身が課題に感じた製品課題を裁量を持って解決すること。「開発案件の質の向上」と「開発工数の確保」の両輪で組織に貢献する、という設計です。
「標準」を作る：コンサル時代の課題から生まれた設定テンプレート
長井氏が Domain Expert になるまでの経験談が、このセッションの背骨でした。導入コンサルタント時代に見えた課題は二重です。お客様にとっては、広く一般的な業務領域でも設計・設定を1から組み上げる必要があり、膨大な設定量と短時間のキャッチアップが負担になり、パッケージのノウハウを実感しづらい。コンサルタントにとっては、一般的な業務領域の案内に工数が割かれ、本来時間を割きたい個社要件に時間を使えない。パッケージのメリットが「工数の機会損失」に直結していたわけです。
「標準設計・標準設定・標準導入手法」があればよい——でも数千万行のコードと80サブシステム・膨大なパラメーターを前に、標準の定義は極めて高難易度です。ここでの着想の転換が効いていました。「標準」が存在しないのは「定義できない」からではなく「一筋縄では決まらない」からでは？ そこで設定を3つに分類します。
| 分類 | 意味 |
|---|---|
| 推奨 | WHI のオススメの設定 |
| 業務 | 業務に合わせて決定する設定 |
| 任意 | 見た目の好みで決めてOKな設定 |
この分類に基づき、「設計」も「設定」もテンプレート（設定ファイル＋設定ドキュメント）としてパッケージ化。テンプレートを取り込むだけで、画面や制御が最初から完成した状態でスタートできるようになりました。お客様は30年の実績から導き出した「人事業務の最適解」から始めて最低限の Fit & Gap だけで完成でき、開発者は複雑な仕様理解から解放されて、あるべき業務の流れを把握した状態から機能改善の設計・実装に入れる。「製品」と「業務」の両方の知見があったからこそ成し得た、という話です。全設定を一律に扱わず「決め方の性質」で分類したところに、ドメインエキスパートの仕事の本質が出ていると感じました。
「ブロッカー」ではなく「伴走者」
活動の実績も具体的でした。Domain Expert が参加したレビューは BugFix 67件＋Function 85件＝合計152件。そして関わり方の哲学が「提案」と「実行」のセットです。設計書は「一緒に書いた」、問い合わせは「代わりに返答した」、リリースノートは「代わりに書いた」、ユーザーヒアリングは「一緒に聞いた」。レビューで指摘だけして戻す「ブロッカー」ではなく、手を動かして開発工数の確保に貢献する「伴走者」であること。有識者レビューが渋滞の原因になりがちな組織には、耳の痛い話かもしれません。
個社要望を「パッケージの標準」へ昇華する
Function の具体例として、個社要望の重要案件2件（異動発令の申請／海外赴任の申請）が紹介されました。ポイントは、目標が「個社要望の達成」ではなく「パッケージ製品として業務を標準化して定義すること」に置かれている点です。
異動発令の申請では、開発者が「個社要望が標準的な業務か判断できない…」と迷うところに「業務としては一般的で標準化できるので、必要性を十分に説明できますよ！」と一緒に設計書を書く。海外赴任の申請では「業務が独特で機能に落とし込むのが難しい…」に「少し特殊な業務なので、一緒に標準化できるか考えましょう！」と一緒に設計を考える。異動発令の例では、所属変更時に組織図に基づいた値が自動入力され強制される仕様に対し、「イレギュラー時は申請者による上書きを可能に」という個社要望からエッセンスを抽出して、全顧客に価値のある機能へ進化させたそうです。
総括：声の「先」を見つめる
総括は冒頭の課題への答え合わせでした。製品が抱える豊富なノウハウ→「人事業務の正解を作り、標準を作っていく」。たくさんのお客様の声→「声の本質を見極めて、本当に重要な要素を抽出する」。市場の変化・ニーズも踏まえ、一人一人がドメイン知識を有したスタートラインに立ち、お客様の本質に向き合った開発へ。場当たり的ではなく「戦略的なアウトプット」へ。締めのメッセージは「人間だからこそ、エンジニアだからこそ、お客様の声の『先』を見つめ、期待を超える価値を創造していく」。
AIの話がほとんど出てこないセッションでしたが、だからこそ1日目からの流れで聴くと際立ちます。実装が安くなるほど価値が上がる「上流の judgment」——何が標準で何が個社特殊かの見極め——を、組織の役割として制度化した実例だと受け取りました。
セッション3：インターネットへの「信頼」の実装 ―Verifiable Credentials に産学連携で挑む話 🔐
（貞弘 崇行氏・藤田 和成氏／伊藤忠テクノソリューションズ、橋本 晃太朗氏・伊藤 有汰氏／慶應義塾大学）
2日目の締めは、慶應義塾大学×伊藤忠テクノソリューションズ（CTC）の産学連携で開発している、国際標準準拠の OSS ツールチェーン「VC Knots」（github.com/trustknots/vcknots、TypeScript & Go）のセッションです。本日のゴールは控えめで、「Verifiable Credentials とは何か」「IHVモデルとは何か」をなんとなく理解して「なんかやっておいた方がいいぞ」と思ってもらうこと、そして VC Knots に⭐をつけてもらえたら喜びます、と（VC＝まず触って理解する、だそうです）。
01 Verifiable Credentials と IHV モデルの基本
まず背景です。証明書のデジタル化は利用シーンが拡大しています。物理的な証明書は窓口で見せる・受け取る対面前提の運用で数分〜数日かかっていたものが、デジタル化されるとスマホ上で「持ち歩き」「見せる」「読み取ってもらう」だけで完結し、手続きが数秒に短縮されます（既存例は銀行口座開設やスマホ新規契約、今後は学割利用や就活でのスキル証明など）。
問題は信頼の根拠です。物理的な証明書は、すかし・複写防止加工・押印、そして高額な偽造費用（卒業証書の例で15万円という話も）で信頼が担保されてきました。デジタルは中身が0と1の羅列でコピーは容易、偽造費用はほぼ無料——では根拠をどうするか。そこで Verifiable Credentials（VC） です。デジタル署名によって真正性や改ざん防止を実現する、機械可読なデジタル証明書フォーマットで、①紙の証明書のデジタル化、②発行元・発行先の特定や提示先の指定、③内容・発行元の改ざん検知、④選択的開示（必要最小限の情報のみ提示）、⑤W3C Verifiable Credentials Data Model 2.0 としての標準化、が特徴です。証明書に限らず、汎用的な「信頼できるデータの容れ物」としても使えます。
VC を扱う登場人物が IHV（Issuer-Holder-Verifier）モデルです。
この図のポイントは、点線の部分です。「検証者は発行者へ確認する必要がない」——これがVCの核心で、発行者に問い合わせずとも検証できることが、プライバシー保護と可用性の両方を支えます。プロトコルは Issuer→Holder 間が OID4VCI、Holder→Verifier 間が OID4VP、フォーマット例が IETF SD-JWT VC で、「プロトコル × フォーマット」の組み合わせが標準の中心です。
国内外の動向も紹介されました。マイナンバーカードのスマートフォン搭載（iPhone は2025年6月開始、Android は2026年秋予定）、政府運営の OpenID Provider である デジタル認証アプリ。実証としては、デジタル庁主導の PoC 2件——大学在学証明＋国民IDで割引運賃を取得する「在学証明×通学定期」（大学が発行者・学生が保有者・鉄道会社が検証者）、山小屋でオフライン検証する QR ベースの「やまのあかしプロジェクト」（登山者証明書、2025年）——に加え、自動車業界のデータ流通基盤 Catena-X（トレーサビリティ・炭素排出量・デジタル製品パスポートを VC で「信頼できるデータ」として流通させる実運用の産業基盤）が挙げられました。
02 標準仕様対応で何が難しいのか：仕様のジャングル
複数の企業・自治体から「VC を自社サービスに組み込みたい」という声（身分証明のデジタル化、本人確認・資格確認を数秒で完結させるオンライン手続の効率化、自社が発行元となる新しい信頼サービス）が来る一方で、立ちはだかるのが「標準仕様のジャングル」です。W3C VCDM、SD-JWT VC、ISO mdoc（ISO/IEC 18013-5)、OID4VCI、OID4VP、さらに DIF PE、DCQL、JWT、CWT、DID……。競合する仕様が多すぎて、明確な答えが少なすぎる。データモデル・フォーマット・プロトコル・識別子のどれを選ぶかも、どう組み合わせるかも、仕様書だけ読んでも答えが出ない。
セッション概要にもあった「specを読むだけで一日終わる……」は、仕様疲れと名付けられていました。JOSE/COSE、OAuth 2.0 関連（DPoP・RAR・PAR）、DIDComm v2、Trust Framework/Trust Registry と裾野も広く、Issuer/Wallet/Verifier のどこから触るかも迷う。しかも実装の難所は仕様そのものではなく「組み合わせた瞬間」に現れます。データモデル/形式 × 発行/提示プロトコル × 暗号/署名/鍵 × 識別子/信頼基盤という4つの仕様レイヤーが同時に絡む「組み合わせ設計」で、結果として実装者は「選ぶ・実装する・つなぐ・追従する」という4つの負荷を背負う。開発者の本音として「早く出したい。でも壊したくない」「標準に乗りたい。でも縛られたくない」「仕様は追いたい。でも本業は別にある」「仕様の違いを毎回書きたくない」が並んだのは、多くの人が頷くところだと思います。開発者が欲しいのは、変更に耐えられる実装の土台です。
03 VC Knots で実装負荷をどう下げるか
その土台が VC Knots です。慶應義塾大学SFC研究所×CTC の共同研究プロジェクト「Trust Knots」で得た知見を、VC 実装の OSS SDK に落とし込んだもので、国際標準対応の主要機能を部品化しています。PoC を閉じさせないためには発行・検証だけでなく Wallet を含めた一連の流れが必要で、Issuer・Wallet・Verifier の三機能を横断して相互運用を検証できる構成、仕様差分を吸収する境界、動くサンプルから始めて要件に応じて拡張できること、の3点が設計思想です。
実装面の話も具体的でした。TypeScript（Issuer+Verifier）はプロバイダーパターンで、各 Provider が kind と canHandle() を持ち Registry が統合します（vcknots({ providers: [...] })）。Go（Wallet）はディスパッチャーパターンで、map[EnumType]Plugin を保持して RegisterPlugin(key, impl) で登録し enum キーで引き出す形です。
プラガブルであることの重要性は3点——エコシステムごとに前提が異なる（ある業界は mdoc、別の業界は SD-JWT VC を好む。一つのフォーマットに固定できない）、暗号の俊敏性（今日の暗号アルゴリズムが明日も安全とは限らない。署名方式や鍵タイプを差し替えられる構造が要る）、作り直し不要で比較検討できる（プラグイン切り替えだけで比較でき、PoC のスピードが変わる）。
OSS である必要性の説明も筋が通っていました。参入障壁を下げる、一企業の信頼に閉じない、相互運用性を実装で示す。OSSとして公開 → オープン標準に準拠 → 相互運用性を担保（他社ウォレット・公共ウォレットとつながる）→ VC コミュニティを拡大、という流れで、EU のデジタルIDウォレット（EUDIW）もソース公開と標準採用が信頼の前提になっている、と。そして品質の裏付けが Conformance Test（OpenID Foundation Conformance Suite）です。通過すれば、自社の主張ではなく外部基準で仕様準拠を示せて、「動作します」を証拠つきで説明できる。現在の状況は、OpenID4VCI 1.0 は Issuer が Conformance パス済みで Wallet 対応中、OID4VP 1.0 は対応中、AWS 対応やドキュメント・サンプルアプリの整備、次の標準対応と続くロードマップでした。
04 産学連携で見えたこと
産学連携パートも良い話でした。CTC 側は企業利用・PoC で VC を使える形へ落とし込み、業務要件と仕様のギャップを設計に還元する。大学側は OSS 実装を通じて仕様の限界と拡張点を発見し、次の研究アジェンダに反映する。実装が、次の研究テーマを生むという循環です（アプリと SDK を同時並行で開発するうちにプライバシー等の課題が浮かび、研究室のアジェンダになった、と）。
学生の視点も率直でした。研究面では、初学者が0から Wallet を実装するのは高いハードルだが、VC Knots で手元に実験環境を作れて卒業研究や実証実験がスムーズに進む。IIW（Internet Identity Workshop）への参加やアイデアソンで視野も広がった。開発面では、参加前は「VC は Issuer/Holder/Verifier、シンプルそう」と思っていたら、実際は想像より「仕様が多い」プロジェクトで、必須項目1つ検証するだけで仕様書を往復し、OAuth 2.0/JWT/DPoP と前提知識も芋づる式に必要だった。ただし仕様が厳密だからこそ実装に専念できる面もあり、VC Knots が細かい仕様対応を吸収してくれるのでアプリ開発者は安全なフローをすぐ動かせる。スクラム開発への参加で優先順位付けも自然に体験できた——という産学連携ならではの学びです。
まとめは「あなたの周りに、こんなシナリオありませんか？」から。社員証・会員証、学修歴・資格証明、サプライチェーンの来歴証明、医療・ヘルスケア（処方箋・健診結果の本人主導提示）、行政・自治体（住民票のスマホ完結）、契約・審査KYC（必要な属性だけを安全に提示）。思い当たったら、まず VC Knots で試してみてください（プロトタイプは数時間から）、と。「信頼は実装できる」「標準差分は避けられないから、設計上の境界で受け止める」という2つのメッセージと、3つのお願い（使ってみて／スターお願いします／仲間になってください）で締めくくられました。
2日目を通して見えた共通テーマ 🧵
AIエージェント、プロダクトマネジメント、デジタルアイデンティティ。分野の違う3セッションでしたが、並べて聴くと1日目からの糸がそのままつながっていました。3つにまとめます。
テーマ1：AIに渡すべきは、賢いモデルではなく「記憶」。 鈴木氏の Enterprise-Bench の数字——モデルを最新にしても+1pt、正しい記憶を渡すと+18pt——は、1日目の黒田氏の「成否を分けたのはモデルの性能ではなくコンテキストの構造」を、別の会社・別のドメインから定量で裏書きした形です。1日目が「コンテキストをどう絞り・供給するか」だったのに対し、2日目は「関係・時系列・権限を持った記憶としてどう永続化するか」まで踏み込んでいて、話が一段具体になった印象でした。
テーマ2：人間の仕事は「本質を見極める」ことへ。 WHI のセッションは AI がほぼ登場しないのに、1日目の「AIは判断を肩代わりしない」（稲垣氏）の実例集のようでした。個社要望をそのまま実装せず、標準的な業務か・標準化できるかを見極めてパッケージの正解へ昇華する。設定を「推奨・業務・任意」と決め方の性質で分類する。これらはまさに、実装が安くなるほど価値が上がる judgment の仕事です。鈴木氏の「あの朝のリプレイ」でも、AIが6ステップを自律実行する中で人間に残ったのは方針のGoと顧客に出す前の最終確認という2つの承認——判断のハンドルでした。
テーマ3：信頼は精神論ではなく、実装できる。 1日目の澁井氏は「誰もが信頼できるソフトウェアを作る仕組みをエンジニアリングする」と言いました。2日目はその各論が2方向から来ました。鈴木氏は、権限フィルタ・ガードレール・ロールバック・Human-in-the-loop という仕組みで「安心して任せられるAI」を作る話。VC チームは、デジタル署名・IHVモデル・Conformance Test という仕組みで「発行者に問い合わせなくても信頼できるデータ」を作る話。対象は違えど、どちらも信頼を設計と検証の問題として扱っていて、「Trust をエンジニアリングの語彙で語る」のが2026年の潮流なのだと感じました。
2日間を通した私の持ち帰りは、鈴木氏の「memory.md は自分の経験からしか学ばない。組織の記憶は、全員の経験から学ぶ」です。個人のメモや CLAUDE.md で AI に文脈を渡す工夫は続けてきましたが、その次の一手は、チームの判断履歴——なぜロールバックせず前方修正にしたのか、なぜこの要望を標準化したのか——を関係と時系列つきで残し、次の判断の材料にすることなのだと思います。まずは自分のチームのインシデント記録に「判断の理由」を書く欄を足すところから始めてみます。
参考
- Developer Summit 2026 Summer（公式）
- セッション1: AIエージェントは「チームメイト」になれるか（鈴木孝規氏）
- セッション2: エンジニアに、お客様の声の「先」は見えているか？（杉田生楽氏・長井弘明氏）
- セッション3: インターネットへの「信頼」の実装（貞弘崇行氏・藤田和成氏・橋本晃太朗氏・伊藤有汰氏）
- VC Knots（GitHub）
- 1日目の参加レポート（本シリーズ。公開後にリンクを差し込んでください）
💡 本記事は筆者個人の聴講メモに基づくレポートです。講演の意図と異なる要約になっている箇所があれば、それは筆者の理解不足によるものです。数値・事例は講演スライドからのメモで、独自に検証したものではありません。セッション1の問い合わせ事例（エーテック製作所・TKT-421 等）は講演内のデモシナリオ（架空の設定）です。