同じ「AI」、2つのカテゴリ

当社の技術ブログには47本の公開記事がある。2026年8月にこれらを insight と engineering の2カテゴリに分類したとき、insight に入ったのはわずか4本だった。残り43本はすべて engineering という結果になった。

この4本という数字が不思議だった。なぜ同じブログの記事なのに、圧倒的多数が片方のカテゴリに偏るのか。もし「AI」や「クラウド」といった技術的な要素を含む記事なら engineering に、経営や組織を扱う記事なら insight に入れる──こんな単純なルールで分類すれば、もっと均等に分かれるはずだ。

ところが、4本のうち1本が矛盾していた。 small-team-ai-dev-flow という記事だ。これは明らかにAIを主題としている。「2〜3人の小チームでAI導入を進める開発フロー」というタイトルからして、技術的な実装記事に見える。

しかしこの記事を実際に読むと、書かれているのは「どうやってコードを書くか」ではなく「チームにAIを導入するかどうかのリソース配分判断」だ。エンジニアが手を動かして実装する話ではなく、技術リーダーや経営層が「この体制で投資を続けるか」「別の方法を選ぶか」を判断するための材料になっている。

同じくAIを扱った別の記事は engineering に入っている。なのにこの記事だけ insight なのか。最初の分類軸「AIが主題かどうか」では、この矛盾を説明できなかった。

属性で切ると、迷宮化する

「モノの属性」と「読者の判断」

分類の軸には大きく2つの切り方がある。属性軸 は「分類される対象側の性質」で切る。「AIが主題か」「技術スタックは何か」「プロジェクトの規模はどれくらいか」──これらはすべて、記事自体が持つ性質だ。

もう1つは 判断軸 。「この分類を見た人が何をするか」で切る。「リソース配分の意思決定を助けるか」「実務の実行を助けるか」「比較検討の材料になるか」──これらは、分類を見た読者の行動や判断に関わる軸だ。

前者の属性軸は直感的で分かりやすい。だが、情報設計の分野ではこの属性軸が読者を迷わせることが知られている。

たとえば、製品開発において JTBD （Jobs to Be Done、ジョブ理論）は「顧客が何を達成しようとしているか」に注目する。マッキンゼーの調査によると、グローバル経営幹部の84%がイノベーションを成長戦略として極めて重要だと答えたが、94%が自社のイノベーション実績に不満を持っているという1。製品開発者は顧客の人口統計学的プロファイルや購買履歴を詳細に把握しているのに、なぜイノベーションは成功しないのか。Christensen らはその原因を「顧客の属性に焦点を当てすぎること」に求めた1。

JTBD の核心的な問いは「どの顧客セグメントが私の製品を買うか」ではなく「顧客が何を達成しようとしているか」である。分類軸も同じだ。「この記事は何の技術を使っているか」ではなく「この記事を読んだ人は次に何をするか」が、読者にとって本当に分かりやすい軸になる。

初期の分類軸「AIが主題かどうか」は典型的な属性軸だった。記事の「中身の性質」で切っていたのだ。

なぜ迷宮化するのか

属性軸が生む最大の問題は、読者に自己判別を強いる ことだ。たとえば社内ナレッジベースで「エンジニア向け」「マネージャー向け」「営業向け」というフォルダ構造を作ったことのある人は、この苦しみを知っているだろう。「自分はどのグループか」という問いに答えるのは、探している情報を探すこととは別の認知負荷だ。

NN/g（Nielsen Norman Group）の調査では、オーディエンスベースのナビゲーション（属性軸の分類）が生む問題として5つのパターンが指摘されている2：

  1. 自分がどのグループかわからない──複数のグループに類別してしまうこともあれば、どれにも当てはまらないこともある
  2. 「に関する」か「向けの」か不明──「教員」というフォルダは、教員の紹介なのか、教員向けの情報なのか
  3. 自己判別が認知負荷を増やす──ユーザーはタスクを達成しに来ているのに、自分のタイプを考えさせられる
  4. 見逃している情報への不安──他のグループに有益な情報があるのではないかと不安になる
  5. コンテンツ重複による管理負荷──同じトピックが複数のグループにまたがるため、管理が煩雑になる

結論として NN/g は「ユーザーはタスク指向であり、自分がどういうタイプかを考えているわけではない」と述べている2。Trusted Choice Insurance のサイトでは、この問題を回避するために、グローバルナビはトピックベースにし、役割ベースのセクションはユーティリティナビに格下げしている2。

また、NN/g の「Comparison Tables」の調査でも、人が多数の選択肢から選ぶ際の意思決定パターンが示されている3。選択肢が多いとき、人は 非補償型意思決定 を行う。つまり、1つの要素（たとえば価格上限）で候補を除外し、他の利点で補償しない。対照的に、選択肢が5〜7個以下の場合に限り、複数の要素を比較検討する 補償型意思決定 になる3。

これは分類設計にとって重要な示唆だ。属性軸が細かく分岐していると、読者は各ノードで「自分はどこに入るか」を非補償型で判断を迫られ、どこかで疲れて離脱する。

メンタルモデルの乖離

分類は「作った側の論理」ではなく「使う側の予測」に合わせるものだ。NN/g の メンタルモデル（Mental Models）の調査では、メンタルモデルは「ユーザーがシステムについて信じていること」であり、事実ではなく信念に基づくと定義されている4。

デザイナーのメンタルモデルは詳細で完成的だが、ユーザーのメンタルモデルは未発達で粗い。両者の間に大きなギャップが生じる4。このギャップが分類の不具合として現れる。作った側は「AI記事ならengineeringフォルダ」と論理的に考えるが、使う側は「チーム体制を考える材料が欲しい」と考え、まったく別の場所を探す。

解決策は原則として2つある4：

  • (a) システムをユーザーのメンタルモデルに合わせる──推奨されるアプローチ
  • (b) ユーザーのメンタルモデルを正確にするよう教育する

NN/g は カードソーティング （Card Sorting）を、ユーザーの情報空間に対するメンタルモデルを発見する手法として推奨している4。各ユーザーは独自のメンタルモデルを持つため、分類は「発信側の構造」ではなく「受信側の予測」に合わせる必要がある。

あなたの会社のファイルサーバーや社内Wikiで、「探している資料がどのフォルダにあるか分からない」と感じたことはないだろうか。その違和感の正体は、おそらく「作った人の属性軸」と「探している人の判断軸」の乖離だ。

軸を「読者の判断」に置き換える

AIが主題か → 実務か・判断か

冒頭の矛盾を解消するために、当社のブログでは分類軸を変更した。新しい軸は「読者が下す判断がリソース配分の意思決定か、実務の実行か」である。

  • insight = リソース配分の意思決定（「何を優先するか」「投資するか」「体制を変えるか」を判断する材料になる記事）
  • engineering = 実務の実行（「どう作るか」「どう直すか」を実際に手を動かして行う記事）

この軸に切り替えた結果、再分類が必要になったのは small-team-ai-dev-flow.md の1本のみ だった。他の3本──ec-replace-timing、perl-ec-modernization-before-replace、freelance-us-workation-freedom──は新設時から insight と判定されており、軸変更前後で分類が変わっていない。

つまり47記事中、実際に「判断軸」にしたことでカテゴリが変わったのは1本だけだった。大きな影響はなかったが、軸の論理性は根本的に変わった。「AIが主題か」という属性から、「読者が何を判断するか」という読者の行動に軸が移ったのだ。

却下した2つの代替案

正直に言おう。一発でこの軸にたどり着いたわけではない。当社の設計記録（ADR 0001）には、検討して却下した2つの代替案が残っている。

却下案(a)：ペルソナ4類型をそのまま category に使う

API 開発者向け、技術リーダー向け、一般ビジネスパーソン向け、経営層向け──といった具合に、読者の属性（役職）で4つのカテゴリに分ける案だ。これは「読者の属性」で切ろうとしたものであり、属性軸思考から抜け切れていなかった。

却下理由は明確だった。公開記事47本を4類型で分割すると、各カテゴリの平均は約12本程度になる。しかも境界が曖昧な記事が多数ある。たとえば small-team-ai-dev-flow は、技術リーダーにとっても経営層にとっても判断材料になる内容を含んでおり、4類型ではどちらに入れるか曖昧になる。結局「現状 engineering 系の細分化は、読者への見せ方として区別する必要がなく、空カテゴリを増やすだけ」という結論に至った。

却下案(b)：URL をクエリパラメータにする

/blog?category=insight のようにクエリパラメータで分類する案だ。技術的には簡単だが、「パス分割の方が明確にブックマーク・共有可能な独立ページになる」という理由で却下した。読者が「このカテゴリの記事一覧」をブックマークしたいと思ったとき、/blog/insight のような独立ページの方が安心して保存できる。これは技術的な優劣ではなく、「ブックマーク・共有」という読者の判断を重視した結果だ。

実際の実装では、/blog/insight と /blog/engineering として独立ページを作成した。両案とも「読者がこの分類を見て何をするか」という視点が欠けていた。案(a)は「読者の属性」で切ろうとしたもの、案(b)は実装者側の都合で切ろうとしたものだ。いずれも属性軸思考の名残だった。

属性を判断に翻訳する3ステップ

読者が自社の分類に応用できるフレームワークを3ステップでまとめる。

ステップ1：既存の分類軸を書き出し、「属性か判断か」を分類する

現在のフォルダ名やカテゴリ名をすべて書き出す。「技術スタック」「対象読者の役職」「プロジェクトの規模」──これらは属性だ。「意思決定材料になるか」「実行手順が書いてあるか」「比較検討に役立つか」──これらは判断だ。

ステップ2：各コンテンツを読んだ読者が「次に何をするか」を想像する

NN/g の「Comparison Tables」で紹介されているAnkerの比較表は示唆的だ3。モバイルバッテリーのスペックとして「3350 mAh」という属性を記載するのではなく、「約1.2回の iPhone 6 充電」という判断に翻訳している。「3350 mAh」という数値を知りたいのではなく、「何回充電できるか（この製品を買う判断材料になるか）」を知りたいのがユーザーだ。この翻訳の発想を分類軸に応用する。

ステップ3：カードソーティングでユーザーのメンタルモデルを確認する

NN/g が推奨する手法であり、実際の社内ナレッジでは3〜5人に「この資料はどのフォルダに入れるか」尋ねるだけでも効果がある4。自分の思う「論理的な分類」と、実際のユーザーが資料を探すときの「直感的な分類」は、意外と異なるものだ。

軸を決めるのと、語彙を揃えるのは別の作業

表記ゆれの実例──17ファイルのタグ統合

分類軸の設計と、語彙・表記の統一は別の作業だ。当社ではカテゴリ新設と同時にタグの表記ゆれ統合も実施したが、これは「同じ時期に実施した別の作業」である。

具体的な変更は以下の通りだ。17本の記事ファイルと1件の執筆規約ファイルが変更対象になった。

変更前変更後ファイル数
Claudeclaude2
Geminigemini1
Ollamaollama1
Meetsourcemeetsource1
ai-agentAIエージェント8
ai-agentsAIエージェント2
LLMllm2
（引用符付き）（引用符除去）1

「固有名詞・製品名も小文字にする」という規約を新設し、同一概念の重複チェックを grep で行う運用を開始した。同じ「AIエージェント」という概念が ai-agent、ai-agents、あるいは大文字小文字混在のまま8ファイルと2ファイルに分散していた。軸を決めた後に「語彙の整理」を行うと、予想以上に散らばっていたことが見えてくる。

NN/g はタクソノミーにおける語彙管理を 統制語彙 （controlled vocabulary）として定義しており、コンテンツ作成者が ad hoc に語彙を拡張できない閉じたリストであるべきとしている5。UX DAYS TOKYO でも、語彙の標準化（同義語・表記ゆれの整理）は辞書として管理し、検索機能と連携させるべきとされている6。

カテゴリとタグの役割分離

分類軸を1つに絞っても、情報を多角的に探せる仕組みは必要だ。その役割分担を明確にすると以下の通りになる。

NN/g は「タクソノミーは backstage のメタデータ構造であり、ユーザーの目に触れるナビゲーションとは別物」と定義している5。UX DAYS TOKYO も「カテゴリは構造、タグは横断」と述べ、「全部カテゴリ化」の落とし穴を警告している6。

  • カテゴリ（insight / engineering）：読者が「今はどちらのモードで読むか」で選ぶ、大きな分岐点。本棚のフォルダのようなもので、1つの記事は原則として1つのフォルダに入る
  • タグ（claude、AIエージェント、information-architecture など）：横断的なキーワードで「同じトピックの別記事」を探すための付箋。同じ記事に複数の付箋を貼れる

当面は category を2値に絞り、タグが多軸の役割を担う第一段階と位置づけている。本棚のフォルダと付箋の使い分けを意識すると、読者の探しやすさと運用の現実性が両立する。

MECEの限界とファセット思考

分類の世界では MECE（Mutually Exclusive, Collectively Exhaustive、互いに重複せず、漏れもない）が理想とされる。しかし現実のコンテンツは、どこかで境界が曖昧になる。

small-team-ai-dev-flow は、その象徴的な例だ。AI を扱った技術記事でありながら、読者の判断はリソース配分になる。MECE を無理に追求すれば、「AI技術記事だが経営判断を含む」という中間的なコンテンツを無理やりどちらかに押し込む必要が出てくる。

そこで有効なのが ファセット （faceted）思考だ。ただしこの記事で推奨しているのは、ECサイトのような「完全なファセットナビゲーション」の一気導入ではない。NN/g は「単一の深い階層ツリーを探索するのは退屈で非効率」であり、ファセットは「複数の次元を同時に絞り込む」ことで探索性を高めると述べている7。Cook.com（フィルターなし）→ Food.com（基本タブ）→ Epicurious.com（ファセット）という進化が、その有用性を示している7。

UX DAYS TOKYO も、ファセット分類は「価格・色・サイズ」といった互いに独立した軸で情報を整理する手法として説明している6。当社ブログの場合、category の insight / engineering は1つのファセット（判断の種類）、タグ群は別のファセット（技術トピック）という具合に、段階的に多軸化を進める方針だ。

User Interviews の調査では、良いタクソノミーは「生き物（organism）」であり、継続的に変化・進化すると述べられている8。最初から完璧なMECEを目指すのではなく、使いながら進化させる姿勢が重要だ。

結論：分類は、誰のためのものか

自社のブログ category 導入で得られた教訓は3つある。

  1. 分類軸は「モノの属性」ではなく「読者が下す判断」で切る──AI記事だからengineering、ではなく「実務か判断か」で切ると矛盾が減る
  2. 軸を決めるのと語彙を揃えるのは別の作業で、両方を同時に完璧にしようとしない──軸が定まってから、表記ゆれ統合に取り組んだ方が整理が進む
  3. MECEを無理に追求するより、ファセットで柔軟に見える仕組みを作る方が読者に優しい──当面 category は2値に絞り、タグが多軸の役割を担う第一段階とする

最後に読者に問いかけたい。

あなたの分類は、誰の判断のためのものですか。

分類・情報設計で詰まっている場合は、コンタクトフォームからご相談ください。

Footnotes

  1. Clayton M. Christensen, Taddy Hall, Karen Dillon, David S. Duncan, “Know Your Customers’ ‘Jobs to Be Done’”, Harvard Business Review, September 2016 ↩ ↩2

  2. Katie Sherwin, “オーディエンスベースのナビゲーション：避けるべき5つの理由”, U-Site（NN/g 翻訳）, 2015年11月10日公開 ↩ ↩2 ↩3

  3. Kate Moran, Taylor Dykes, “Comparison Tables for Products, Services, and Features”, Nielsen Norman Group, 2024年2月9日 ↩ ↩2 ↩3

  4. Megan Chan, “Mental Models and User Experience Design”, Nielsen Norman Group, 2024年1月26日 ↩ ↩2 ↩3 ↩4 ↩5

  5. Page Laubheimer, “Taxonomy 101: Definition, Best Practices, and How It Complements Other IA Work”, Nielsen Norman Group, 2022年7月3日 ↩ ↩2

  6. イケダマリカ, “タクソノミー（Taxonomy）”, UX DAYS TOKYO, 2025年10月21日 ↩ ↩2 ↩3

  7. Kathryn Whitenton, “Filters vs. Facets: Definitions”, Nielsen Norman Group, 2014年3月16日 ↩ ↩2

  8. Lizzy Burnam, “How to Create An Effective Taxonomy for UX Research”, User Interviews, 2022年11月1日 ↩