第4回サービスデザイン関連ガイドライン改訂に係る検討会

概要

日時

令和8年(2026年)1月30日(金)10時00分から12時00分まで

場所

オンライン会議

議事次第

  • 1.開催趣旨のご説明
  • 2.各ガイドラインに対する意見収集
  • 3.結果の取りまとめ

資料

配布資料

  • 付議対象ガイドラインの概要 ※構成員限り
  • 各ガイドライン案 ※構成員限り

出席者一覧

構成員(50音順/敬称略)

  • 赤坂 文弥(産業技術総合研究所 人間社会拡張研究部門 主任研究員、北陸先端科学技術大学院大学 客員准教授、東京農工大学 客員准教授)(*)
  • 伊藤 芳浩(NPO法⼈インフォメーションギャップバスター 理事⻑)
  • 大井 美喜江(三菱電機株式会社 統合デザイン研究所)
  • 岡本 鉄兵(流通経済大学 流通情報学部 准教授)
  • 北崎 允子(武蔵野美術大学 造形学部 視覚伝達デザイン学科 教授)
  • 中尾 洋子(デザイナー(インクルーシブデザイン))
  • 中山 郁英(立命館大学 経営学部 准教授)
  • 長谷川 敦士(武蔵野美術大学 造形構想学部 教授、株式会社コンセント 代表取締役)
  • 比嘉 夏子(合同会社メッシュワーク 代表社員、山梨県立大学 特任准教授)
  • 平井 康之(九州大学 大学院芸術工学研究院 教授)
  • 平沢 尚毅(⼩樽商科⼤学 社会情報学科教授)
  • 福住 伸一(特定国⽴研究開発法⼈理化学研究所 ⾰新知能統合研究センター副チームリーダー)

デジタル庁(事務局)

技術検討会議 サービスデザインタスクフォース

(*)日程が合わず当日欠席のため、後日個別に意見収集を実施(個別意見収集の内容は本議事に含む)

議事概要

構成員からの主な意見(要約)

1. 開催趣旨のご説明(質疑応答)

質疑なし。

2. ガイドライン改訂方針に関する意見収集、3. 全体に対する意見収集

<DS-630.1ユーザーリサーチガイドライン>
  • 2.1.2「利用者調査(ユーザーリサーチ)」:SNSの発話・レビュー分析などデジタル手法を追記し、公開範囲やスクレイピング可否、同意等の留意点を明示するべきである。
  • ワークショップを手法例に加え、観察・面接を補完する適用条件を示すとよい。
  • 2.1.7「リスク」:身体・財産・プライバシーに加え、ラベリングや偏見助長など社会的影響も含むよう拡張し、低減策の例を添えるべきである。
  • 2.1.8「利益」:経済・知識的利益に加え、要配慮参加者の権利獲得・困りごと解消を追記し、9.1.2「調査参加者に一般化可能な知識をもたらす見込みがある場合」と整合を取れるようにするとよい。
  • 2.1.9「リプレゼンテーション」:「社会的立場」は曖昧なため、社会階層・社会経済的地位(SES)等の指標で明確化したい。
  • 3.5「適用を除外できるケース」:一律の適用除外ではなく、手続きの簡略化に留める。必要最小限の要件(告知方法や記録の簡素化等)を例示するとよい。
  • 3.5.1「教育・訓練のための安全な環境での実施」:安全側の要件(範囲限定、記録の扱い、退出自由)と簡略化の限度を明示したい。
  • 4.1「プロジェクトの立ち上げ及び初動における利用者調査」:調査の意図・必要情報・意思決定への影響を明確化し、企画・要件定義への接続を強調すべきである。
  • 4.2.3「委託先との契約における留意事項」:同意取得・管理の確認にとどめず、依頼側要望の実装(実現性検討、代替案、改善)まで踏み込む必要がある。
  • 契約に遵守条項、監査権限、是正義務、教育要件を明文化することが望ましい。
  • 4.3「サービス・業務企画」以降:リスクマネジメント、部分適用の参照動線、AI評価の意義を補強したい。
  • 4章:細分化自体は有用。見出し間の関係を図解し、「何のため・どのフェーズ・どう進め・どう選ぶ」の軸で再構成する必要があると考える。
  • 手法には選定基準を添え、同意に保存期間・廃棄方法を明記。分析の多様性・AIの限界、運営不全時の代替、規模差の目安も示すとよい。
  • 5.4「同意の取得」~5.7「書面による同意の省略」:書面同意の原則と例外を明確化する。5.5の見出しは「同意の成立要件」から「データの取り扱いの条件」に改題し、同意形式と取り扱い条件(匿名化・公開性・機密保持)を分離。5.7の適用前提も明記したい。
  • 5.4「同意の取得」:口頭・電子同意や柔軟なタイミングを許容し、記録方法のみ標準化する方法がある。
  • 倫理委員会承認が必要になり得る旨、対象例・手順の概要、相談窓口を追記したい。
  • 倫理は判断フローに加えてチェックリスト(高負荷作業・身体介入・機微情報)を整備し、該当時は上長から倫理委員会へエスカレーションとするとよい。範囲と適用基準も明示するとよい。
  • 要否判断フローを示し、自主実施と委託で責任・記録の扱いを区別するとよい。
  • 当事者だけでなく手話通訳・介助者・家族等の支援者にも、中断権・プライバシー・守秘・退出権が及ぶ旨を明記し、同席者情報の扱いを整理するとよい。
  • 7.1.1「要配慮参加者の脆弱性への配慮」:対象者選定理由を説明可能にすることを要件化するとよい。「研究」は「調査」へ修正していただきたい。
  • 公平性基準について、人口統計に基づく属性比率の目安設定を検討し、限界も併記して継続議論事項とする。
  • アファーマティブアクション・マイノリティ包摂について、割合に依存せず、極少数・複合特性も包摂できるよう設計・リクルートを調整し、優先的リクルートを認める方針がよい。
  • 8.1「データの保護」&8.2.1「データの開示」:具体策(アクセス制御、保管期間、暗号化、持ち出し禁止、監査ログ、廃棄手順)を明示したい。匿名化後の再識別リスクと防止策(抑制、閾値、差分プライバシー等)を注記するとよい。
  • 8.3「AIを活用した分析における配慮」:ステレオタイプ増幅への注意、人間による解釈の必須化、AI利用とリスクを説明の上での同意取得、無断タグ付けの禁止を規定したい。
  • 9.3.1「法定代理人による許可及び調査参加者の同意に必要な要件」:本人確認ができる場合は本人同意を原則とし、不可時のみ法定代理人に確認と明記するとよい。障害の有無のみで代理人必須と誤解させない工夫が必要。
  • 団体・利用場所経由の周知、特定条件選抜への抵抗への配慮、横断ニーズの事例(例:タッチパネルと視覚障害者・育児中保護者)を記載するセクションがあることが望ましい。
  • 9.1.2「調査参加者に一般化可能な知識をもたらす見込みがある場合」:2.1.8「利益」と表現整合を取る(便益の範囲を個人とコミュニティ双方で明確化)必要がある。
  • 匿名性や、多様な特性を持つ利用者の参加を脅かす具体例(顔出し強制、実名紐づけ、メタデータ漏えい)と回避策を提示したい。アウトプットの規格・プロセスアセスメント対応も示すとよい。
  • 現場適合について、典型的使用シナリオ(短期検証、探索ヒアリング、オンライン観察)を提示し、目的・フェーズ・リスク別ナビゲーションを設計するとよい。
  • 倫理のレベル感について、「必要十分」の基準を明記し、低・中・高リスク例とチェックリストで過度な厳格化を回避すると、「緩くてよい」誤解も防げるのではないか。
  • 行政職の学習に際しては、導入版・eラーニング等で基礎リテラシーを底上げし、委託時も職員の理解・レビューを義務化、役割分担を明確化するとよい。
  • 情報・コミュニケーションのバリア除去、フラットな対話のワークショップ、補完サンプリングと記録の透明化、意味的飽和基準の当事者参画・コデザイン化するとよい。
  • 質的調査について、マイノリティ含有時はn数を40〜50人まで拡大し得る目安、KJ法、複数分析者、トライアンギュレーション、少数意見のアンプリファイを明文化するとよい。
  • 「リサーチ参加者」に統一し「被験者」は避ける。「要配慮」「合理的配慮」「倫理的配慮」の定義と適用関係を一貫化したい。
  • タイトル・表紙をウェルカミングに再設計し、サービス設計12箇条等との結び付きを強化したい。三文書共通の上位フレームと全体構造図で位置づけを明示し、探索的観点を初期から組み込むとよい。
  • 社会調査・フィールドワークの倫理要綱(AAA (American Anthropological Association) の倫理要綱、Association of Internet Researchersのガイドライン)を参照枠として提示し、実務に使える具体例(行為がもたらし得る倫理的な負の影響)を併記するとよい。あわせて、マーケティングリサーチ分野の倫理規程・国際方針も比較参照し、ユーザーリサーチ適用時の判断基準を補強するとよい。
  • ユーザーリサーチの基本形(ISO HCD図)を示し、絶対遵守ではない位置づけと各フェーズの必須事項を明記したい。
<DS-670.1ユーザビリティガイドライン>
  • 3章:「何を誰に、なぜ」を章の冒頭で明示し、対象と目的を本文前に定義する必要がある。タイトルも「使いやすいシステムの計画」など、実装に先立つ計画の性格を反映した名称へ改めるべきである。
  • 3.3.8「技術・システムに対する利用者の不安及び期待」:公平性、情報不提示、人間とシステムの役割分担などの不安の所在を体系的に特定し、課題抽出→仮説→検証→是正までの評価手順を定義する。一般的タッチポイント以外も対象化し、評価プロセスを運用可能な形で明文化するとよい。
  • 5.3.1「利用者向けフィードバックフォームの設置」:記述が簡略で、ユーザーリサーチガイドラインとの適用関係が不透明である。フォームで得たフィードバックの収集・分類・分析・優先度付けをユーザーリサーチのプロセスへどう接続するか(同意・プライバシーの扱いも含む)を明記し、両ガイドの関係性をここで示すとよい。
  • 5.4「運用中のAIシステムの評価」:AI評価章が追加された点は評価できる。併せて、期待外れ応答発生時の次の行動のシステム側ガイド、誤認識・不確実性の提示、人間の確認を促すUIなど、具体的な評価観点・設計配慮を補強すると有用である。
  • 全体として文字量が多く読みのハードルが高い。要点を一覧化する表や図を導入し、章間の関係や判断フローを視覚的に示すと理解と運用が進むのではないか。
  • 情報提供が一方向で、受け手が理解できているかの確認視点が弱い。理解度の把握(説明後の確認質問、要約のリピート、理解困難時の代替説明)を設計要件として組み込むべき。
  • 設計の誘導性(デフォルト効果等)を明示し、許容範囲の考え方を定義する。行政文書が前提としがちな「合理的経済人」像を見直し、誤読・読み飛ばしを前提に、認知エラーを起こしにくい情報設計や確認プロセスを整える。UK GDSの「良い行政サービス」の参照で良い状態の共有を促進するとよい。
  • 三観点「利用時の品質(アウトカム)」「ユースエラー(使用中)」「AIシステム」を連関する枠組みで示し、エラーをどうカバーして最終的品質へ結びつけるかの流れを明文化したい。AI関連の記述は、期待外れ応答時に次の行動をシステムがガイドする等、具体的留意点を補うとよい。
  • 「ユースエラー(使用中)」を人ではなく設計起因(手順、情報提示、環境要因)として定義し直す。長時間精読が困難な状況も前提に、タスク・評価設計へ反映し、評価手順・合否基準・補助の要否を明記するべきである。
  • 視覚情報が得にくい利用者は顔位置合わせが困難なため、「見えていなければ合わせにくい顔認証端末の設置」はNGと明記する。顔認証があるだけで十分という設計者の思い込みを避ける必要がある。
<DS-671.1ユーザビリティ導入ガイドブック>
  • 2.1.1「ユーザビリティの観点」:「利用状況の網羅性」はSQuaREでは既に削除済みのため記述見直しが必要である。「SQuaREでもユーザビリティは『利用時の品質』として定義」の一文は誤りのため削除すべき。
  • 「JIS X 25010:2013(ISO/IEC 25010:2010)」は最新版へ更新したい。同章の規格言及は、ユーザビリティと品質モデルの関係を誤解なく伝えるよう文言調整を行う必要がある。
  • 2.5「認知とバイアス」:章構成を再編し、認知の多様性(例:識字障害等)を独立セクションで扱いたい。健常者バイアスや提供者側視点の偏りを明示し、是正のための具体指針を追加。用語を「利用者」に統一し、UXをエンドツーエンドの体験として定義したい。サービスデザインとユーザビリティの位置関係を図示し、時間軸で使用プロセスを捉える視点を本文に組み込むとよい。
  • 3.1「デザインと倫理」:概念的説明に留まらないよう、ケースに即した具体例を追加したい。ある行為がもたらし得る倫理的な負の影響の例を併記し、何をすれば配慮といえるのかを実務レベルで理解できるようにするとよい。
  • 6章「使用エラーのメカニズム」〜9章(関連章):ユースエラーの説明がレガシーな安全分析に偏り、やや古い。このあたりは次回以降の検討で専門家と更新した方がよい。
  • セキュリティにおける人間の要因とユーザビリティの結び付け(例:認証手順の使いやすさと誤操作の関係)を具体例・評価観点で示すべきである。
  • 標準ガイドライン(JIS/ISO、X 8341、Z 8520、Z 8522、ISO/IEC 25000系等)とのクロスリファレンスを整備し、どの規格のどの要求に対応するかを明確化したい。
  • ガバナンスやデジタル人材育成の項に、人間中心の考え方を反映する(役割定義、教育、レビュー体制)とよい。
  • 導入(序文)・章別最低要件として、ベンダー・部署ごとに運用がばらつかないよう、各章に「最低限これだけは実施」の要件(チェックリスト)を明文化する必要がある。必須/推奨の区分、証跡、責任者、承認ゲートを導入部に一覧化したい。
  • 図表・事例が豊富で読みやすい一方、情報量が多い。逆引き(やりたいこと→参照先)項目を設け、「どの場面で何を知りたい時にどこを見るか」を明確化すべきである。ガイドブックをAI等で検索しやすくする設計(見出し設計、用語統一、メタデータ付与)を検討し、実運用の使用シーンに合わせるとよい。ユーザーリサーチガイドラインは単体発行ではなく、ユーザビリティガイドライン/導入ガイドブックへエッセンスを組み込む改訂方針の理解を前提に、内容の重複や参照関係を最適化するとよい。
  • 障害者やマイノリティの当事者の意見を後付けにしない。設計の早期から当事者をスタッフとして参画させ、継続的に合意形成・検証を行うプロセスをガイドラインに明記するとよい。当事者参加を要件化する(対象、関与の段階、意思決定への反映方法、記録等)ことで、形式的なヒアリングに終わらせないスタンスにするとよい。
  • 利用者体験は所管をまたいで連続する前提を明文化し、複数省庁でも外部一貫性を確保する必要がある。職員もユーザーであることを明示し、現場負担リスクを減らす設計・運用を求めたい。
  • 「デザイン原則」は上位原則→具体規範→適用例で再構成したい。既公開文書は「利用者特性→感覚特性→情報支援機器」で整理し、合理的配慮と要配慮の関係、社会モデル、対話による調整、同一内容を同時点で得る権利を明記したい。まず設計を包摂的に高め、個別配慮への依存を減らす。分量の多さは「時短」を基本に、生成AI活用と見出し・要点サマリ等で短時間把握を支援するとよい。エクストリームな良実践(例:字幕の倍速視聴)の一般化を促したい。
  • 行政サービスの横断性を前提に、属人的でなくチーム体制(責任者・実務担当・関係部局)を原則化し、役割と意思決定を可能な範囲で具体化するとよい。現段階は知識提供を優先し、次段階で読みやすさや理解支援(講演・イベント等も含む)を強化する「届ける」設計へ移行する方針が望ましい。
<ガイドライン群体・その他>
  • 東京都のサービスデザインガイドラインが企画・構想段階での活用を明示している点を踏まえ、本ガイドラインも標準ガイドラインとの関係性を序文で明確化し、設計・運用・評価の各段階で「部分的にどう使うか」を示すようにしてほしい。具体的には、ライフサイクル別の参照動線やクロスリファレンス(設計→要件・同意、運用→データ保護、評価→AI評価・改善)を導入に配置する。
  • 「障害」の表記は、当事者団体の考え方(障害は社会システム側にある)や内閣府の議論、研修現場の運用(漢字表記)を踏まえ、行政内で統一し理由を明記するべき。ひらがな表記の是非も含め、方針を一貫させる必要がある。
  • 3つの文書全体を通じて、「対象者/参加者」の用語は方針を明確化し、「参加者」へ統一するなど一貫性を担保した方が良い。用語統一の根拠(国際動向、ヘルシンキ宣言等)も示す必要がある。
  • アクセシビリティについて、視覚過敏・聴覚過敏への配慮を明記し、OSの白黒反転(ディセーブル)モード等の設定がブラウザ・ウェブ上でも反映されるよう、画像生成のボタン・案内などの実装方針を調査設計時のチェック項目に含めたい。研究環境・刺激提示のアクセシビリティ要件として、OSレベル設定とウェブUIの整合性を評価したい。
  • 3文書を通じて、民間本との差別化と行政向けの意図を明示し、行政固有の論点(公平性・説明責任・法令遵守・アクセシビリティや合理的配慮・現場制約・公共性、信頼等)を前面化して「省庁用の核心」を示すとよい。
  • FMEA/FTA (Failure Mode and Effects Analysis, Fault Tree Analysis)は機械系起源だが、行政システムに不可欠な信頼性確保の観点として妥当である。アジャイルや構築後の修正が一般的な現状でも、保証ロジックとしての有用性は高い。読み手に重要性が伝わるよう、記載の背景(採用理由・位置づけ)と適用場面(企画・設計・運用での使い方)、得られる効果(リスク特定・再発防止)を簡潔に補足し、現代的開発文脈との接続を示したい。

以上