Rasepi Blog

読者とライターは異なるメンタルモードにあります。なぜどのツールも同じUIなのでしょうか？

2026-04-03T00:00:00Z

今すぐ Confluence を開き、読む必要のあるドキュメントを見つけてください。何が見えますか?

ツールバー。編集ボタン。コメントボックスページ履歴リンク。必要のないナビゲーションでいっぱいのサイドバー。パンくずメタデータフィールドパーミッション表示オーサリングインターフェース全体が、あなたが読むためにここに来たテキストを包み込みます。

質問の答え、プロセスの次の3つのステップ、10分後の会議の前に参照する必要のあるポリシーなどです。

あなたは消費するために来たのです。インターフェイスは、あなたが創造するために来たと仮定しています。

これは、ほとんどすべてのドキュメントプラットフォームのデフォルトです。Confluence、Notion、SharePoint、GitBook、Nuclino、Slite。これらはすべて、読み手と書き手に同じ環境を提示しています。ページはページです。いくつかのパーミッションゲートボタンの有無にかかわらず、誰もが同じビューを得られます。

それが普通だと感じるのは、他に何もなかったからです。しかし、それはデザイン上の決定であって、自然の法則ではありません。そして、それは間違ったものなのです。

読むのも書くのも同じインターフェースは認知的なオーバーヘッドを生む](/ja/blog/img/readers-writers-ui.svg)

読み書きは同じ認知作業ではありません

これはUIの好みではありません。脳の働き方の根本的な違いです。

文章を書くときは、生成モードです。構成し、整理し、何を盛り込み、何を省くかを決めているのです。フォーマットオプション、構造コントロール、メディア埋め込み、メタデータフィールド、バージョン履歴、コラボレーション機能といったツールが必要です。インターフェースは、あなたにパワーと柔軟性を与えるものでなければなりません。

読むときは、受容モードです。スキャンし、フィルタリングし、関連するものを抽出し、次に進もうとしています。必要なのは明快さです。すっきりとしたタイポグラフィ、焦点を絞ったレイアウト、邪魔になるものの最小化。インターフェースは邪魔にならないものでなければなりません。

認知心理学には、このための明確なフレームワークがあります。1980年代後半にJohn Swellerによって開発されたCognitive Load Theoryでは、本質的負荷（教材自体の難易度）、本質的負荷（学習と統合の努力）、外在的負荷（役に立たない環境が加えるものすべて）を区別しています。読者に見えるすべてのツールバー、サイドバー、編集ボタンは余計な負荷です。コンテンツを理解する助けにはなりません。それは積極的に注意を引くために競合します。

マルチメディア学習に関する[Mayer and Moreno (2003)] (https://doi.org/10.1207/S15326985EP3801_6)の研究では、余計な要素を減らすと、理解も定着も向上することが実証されています。彼らの一貫性の原則は直接的です：オーサリングのコントロールを読者に見せるドキュメンテーションのインターフェースは、すべてのページロードにおいてこの原則に違反しています。

**読者はライターのツールを見る必要はありません。とにかく見せることは中立ではありません。それは理解に対して積極的に有害です。

現在のプラットフォームはこれをどう扱うか(ほとんど扱いません)

存在するものを見てみましょう。

Confluenceには閲覧モードと編集モードがありますが、閲覧モードはプラットフォームのナビゲーション、メタデータ、ページツリーに囲まれています。編集ツールバーは編集していないときには消えますが、"これは編集可能なウィキのページである "という精神的なフレームは完全に消えることはありません。すべての読者は「編集」ボタンを目にします。ページはささやきます：あなたはこれを変更することができます。

この点では、Notionの方がひどいです。この点で、Notionはもっとひどい。その中心的なデザイン哲学は、すべてが常に編集可能であるということです。どこをクリックしても入力中。それはライターにとっては素晴らしいことです。誤って何かを修正する不安なしにコンテンツを吸収したい読者にとっては最悪です。Notion自身のテンプレートギャラリーを見ればわかります。すべてのテンプレートはワークスペースであり、出版物ではありません。

SharePointは技術的には閲覧用と編集用の異なるページレイアウトをサポートしていますが、全体的な体験は依然として企業イントラネットです。読者は、理解するために最適化されたドキュメントを読んでいるのではなく、企業ツールの中にいるように感じます。

GitBookは、そのクリーンなドキュメンテーションスタイルの出力により、リーディングファーストの体験に最も近いものとなっています。しかし、そこでも読者体験は、読者が技術文書を見ている開発者であるという前提で提供されています。一般的な知識消費者のために設計されているわけではありません。

これらのプラットフォームはいずれも、読むことを書くこととは根本的に異なる行為として扱っていません。ツールバーを隠して文章を書くのと同じ扱いなのです。

現在のツール：1つのインターフェイス、すべての読者](/ja/blog/img/readers-writers-current-tools.svg)

##単一のインターフェースのコスト

これは単なる美学の問題ではありません。測定可能な結果をもたらします。

情報過多による理解力の低下

Journal of Consumer Researchに掲載された研究](https://doi.org/10.1086/209336)によると、情報過多は意思決定の質を低下させ、その影響は関連性のない情報と関連性のある情報の比率が大きくなるにつれて大きくなります。目に見えるオーサリング・コントロール、ナビゲーション・ツリー、メタデータ・フィールドを持つドキュメント・ページは、書くためにそこにいないすべての読者にとって、その比率を増加させます。

コンテキスト・スイッチングには実際のコストがあります。

インタフェースのシグナルが "あなたはこれを編集することができます "と言うとき、それは "これを読んでください "とは異なる認知フレームを活性化します。カリフォルニア大学アーバイン校でのグロリア・マークの研究では、注意とマルチタスクについて、コンテキスト・スイッチの後、完全に集中し直すのに平均23分15秒かかることがわかりました。編集を一瞬考えた読者は（たとえ誤字を直すためであっても）、読書モードから引き離されてしまったのです。これは仮説ではありません。Notionを使ったことがある人なら誰でも、テキストを選択するためにクリックして、誤ってタイプし始めた経験を知っています。

同じコンテンツでも、読者と書き手のニーズは異なります。

ライターは、構造、フォーマットマーカー、ブロックタイプ、メタデータ、コラボレーションのシグナルを見る必要があります。完全な機械が必要なのです。

読み手は、きれいなテキスト、明確な階層構造、探している情報への最短経路を見る必要があります。必要なのはコンテンツであり、機械ではありません。

同じインターフェイスから両方を提供することは、どちらも実際に行っていることに最適化されたエクスペリエンスを得られないことを意味します。

そして、3つ目のオーディエンスがいます：AI

これは複雑な問題で、既存のプラットフォームはまったく準備ができていません。

2026年のドキュメンテーションには、2人ではなく3人の消費者がいます：

1.コンテンツを作成し維持するライター。 2.コンテンツを視覚的に消費する読者。 3.プログラムでコンテンツを取得、解析、合成するAIシステム 3.

これらのオーディエンスはそれぞれ、同じ基礎となるコンテンツに対して根本的に異なるインターフェイスを必要としています。

ライターには、豊富な編集ツール、コラボレーション機能、構造的なコントロールが必要です。読者は、気が散るのを最小限に抑えた、すっきりとした、集中力のあるプレゼンテーションを必要としています。AIは、明示的なメタデータ（鮮度シグナル、分類ラベル、ブロックレベルのアドレス指定、きれいなセマンティックマークアップ）を持つ、構造化された機械解析可能な出力を必要とします。

Builders, Not Developers](/ja/blog/builders-not-developers-how-claude-changed-devrel/)で述べたように、AI仲介者は、知識労働者の増加するシェアにおいて、すでにドキュメントの支配的な消費者となっています。GitHubの2024年開発者調査によると、企業開発者の97%がAIコーディングツールを使用したことがあります。2026年には、開発者の84%がAIツールを常用し、全コードの41%がAIによって生成されるようになります。

これらのAIシステムは、あなたのサイドバーやツールバーを気にしません。必要なのはクリーンなデータです。そして、読み手の視点と書き手の視点を混同しているプラットフォームは、AIが消費可能な表面と人間のオーサリングの表面を混同しています。1つのインターフェースに3つのミスマッチがあるのです。

3つのオーディエンス、3つの異なるニーズ](/ja/blog/img/readers-writers-three-audiences.svg)

ラセピはどのように体験を分けるか

ラセピは、コンテンツを作成することとコンテンツを消費することは異なる活動であり、異なるインターフェースに値するという原則に基づいて構築されています。

書き手の環境

ラセピで文章を書くとき、完全なオーサリング環境を手に入れることができます。TipTapによるリッチテキスト編集、ブロックレベルコントロール、翻訳ステータスインジケータ、有効期限管理、コラボレーションツール、コンテンツ構造ビューなど、ライターが高品質なドキュメントを作成・維持するために必要なものが全て揃っています。

ライターが機械を見るのは、機械が必要だからです。

<スクリーンショット：Rasepi ライティング環境 -->

読み手の環境

誰かがラセピの文書を読むとき、クリーンで、集中した読書体験を見ることができます。編集用のクロームはありません。ツールバーもありません。修正できますよ」というシグナルもありません。ただコンテンツが、理解とスキャンのために最適化されたレイアウトで表示されます。

読者は編集ボタンを見ません。彼らは何かを学ぶため、プロセスをたどるため、答えを見つけるためにここにいるのです。インターフェイスはその意図を尊重しています。

<スクリーンショット：ラセピの読書体験 -->

AIの表面

AIコンシューマーのために、ラセピは構造化されたAPIを通じてコンテンツをフルメタデータで公開します。各ブロックには、鮮度スコア、翻訳状況、コンテンツハッシュ、分類ラベルが含まれています。AIシステムは、ブロックレベルでコンテンツを照会し、鮮度によってフィルタリングし、古くなったものや草稿を除外し、必要な構造化データを正確に取得することができます。

Wikiのページをスクレイピングしてベストを期す必要はありません。AIは、読み手や書き手と同じように、専用のインターフェースを手に入れることができます。

<スクリーンショット：ラセピAIサーフェス/API -->

コンテンツレイヤーは1つ、インターフェースは3つ

重要なのは、コンテンツのコピーを3つ維持しないことです。これは、Stop Maintaining Five Copies of the Same Documentで説明した、5つのコピーのオンボーディングの問題ではありません。

これは、構造化されたブロックとして保存された1つのコンテンツレイヤーで、3つの異なるオーディエンスに最適化された3つの異なるビューを通して提供されます。

書き手はブロックを編集します。読者は、組み立てられ、スタイリングされたコンテンツを見ます。AIはメタデータを含む構造化データを照会します。同じブロック。真実のソースは同じ。消費者ごとに異なるプレゼンテーション・レイヤー。

これはブロック・レベル・アーキテクチャだからこそ可能なのです。各コンテンツは、独自のメタデータを持つ個別にアドレス指定可能なユニットです。それらのブロックを、誰が求めているかによって、異なる形で提示することができます：

| オーディエンス｜ニーズ｜ゲッツ |----------|-------|------| | 書き手**｜フォーマット、構造、コラボレーション、メタデータ｜ブロックレベルのコントロールを備えた完全なオーサリング環境 | 読者**｜クリーンなテキスト、明確な階層構造、高速なスキャン｜フォーカスされた読書ビュー、クローム編集なし｜AI*｜構造化されたテキスト、構造化された構造、コラボレーション、メタデータ｜ブロックレベルのコントロールを備えた完全なオーサリング環境 | AI*｜構造化されたデータ、鮮度スコア、分類｜完全なメタデータを備えたブロックレベルのAPI｜AI｜構造化されたデータ、鮮度スコア、分類｜完全なメタデータを備えたブロックレベルのAPI

見た目以上に重要な理由

これを読んで、あなたはこう思うかもしれません。同じものの異なるビュー。そんなに重要なことか？"

とても重要なことがわかりました。

読者の信頼

人は公開されているように見えるコンテンツを信用します。ページが誰でも編集できるウィキのように見えると、読者は無意識のうちにそれを否定します。同じコンテンツがきれいで、出版物並みの読みやすさで表示されると、より権威があります。これは不合理ではありません。誰かが真剣にプレゼンテーションに取り組んだというシグナルであり、それは彼らがコンテンツにも真剣に取り組んだことを意味します。

ニールセン・ノーマン・グループはこのことを幅広く研究しています。彼らのコンテンツの信頼性に関する研究によると、デザインのクオリティとプレゼンテーションは、ユーザーがコンテンツの信頼性を評価する際に最も頼りにするシグナルです。乱雑なエディタビューは、それが表示するコンテンツの信頼性を積極的に損ないます。

ライターの生産性

専用のオーサリング環境で作業するライターは、"読んでいるのか、書いているのか "をコンテクストで切り替える必要はありません。ツールがそこにあるのは、それがそこにあるべきものだからであって、インターフェイスが誰がそれを見ているのか判断できなかったからではありません。

AIの信頼性

AIシステムが構造化されたメタデータを持つ専用サーフェスを持つことで、何を取得し、何を除外するかについてより良い決定を下すことができます。ブロックを回答に含める前に鮮度スコアをチェックできます。分類ラベルを尊重することができます。言語、ステータス、オーディエンスによるフィルタリングも可能です。AIが人間の読者のためにデザインされた同じHTMLページをスクレイピングしているときには、そのようなことは不可能です。

メンタルモデルの転換

ほとんどのドキュメンテーション・プラットフォームの基本的な前提はページが単位であり、誰もがページと相互作用します。

ラセピの前提は違います：ラセピの前提は違います：「ブロックが単位であり、様々なオーディエンスが目的のために作られた表面を通してブロックと対話する」_。

それは建築上の小さな違いのように聞こえます。そうではありません。それは、AIシステムに偶然コンテンツを見せるツールと、意図的に見せるツールの違いです。たまたま読みやすい文章を書く環境と、ゼロからデザインされた読書体験の違い。1つで十分なインターフェースと、3つの優れたインターフェースの違い。

ドキュメンテーションはもはや、ただ書いて読むだけのものではありません。書かれ、読まれ、照会され、翻訳され、採点され、分類され、大規模にAIシステムに提供されます。単一のインターフェイスでそのすべてを最適化することはできませんし、できるように見せかけることが、誰も読みたがらないWikiや、AIアシスタントが機械的に消費されるように設計されていないページから答えを引き出すような事態を招いたのです。

読者と作家は異なる精神モードにあります。AIはまったく別のモードです。インターフェースはそれを反映すべきです。

2026年のドキュメントの現状：次の時代を定義する5つのトレンド

2026-04-03T00:00:00Z

数ヶ月に一度、ただ本を読むために朝を迎えます。Rasepiのコードでも、GitHubの課題でもありません。競合他社のブログ、業界レポート、基調講演の発表、開発者アンケート。前四半期に出荷されたもので、ドキュメント、ナレッジマネジメント、AI支援ワークフローに関連するものなら何でも。

先週この調査を行ったところ、予想以上に鋭い結果が出ました。どの発表が画期的だったからというわけではありませんが、5つの別々のトレンドが収束しつつあり、それらを並べると、今後2年間にドキュメンテーション・プラットフォームが何をする必要があるのか、非常に明確な絵が浮かび上がってきました。

以下は、私が見つけたものです。

1.AIが主な読者。人間ではありません。

GitBookはAIドキュメントのデータレポートで印象的な数字を発表しています：AIによるドキュメントの読者は2025年に500％以上増加。500パーセント。丸め誤差ではありません。

一方、Stack Overflowの2024年開発者調査によると、開発者の61%が1日30分以上かけて答えを探しています。しかし、検索方法は変化しています。GitHub独自の調査では、エンタープライズ開発者の97%がAIコーディングツールを使用していることがわかりました。2026年には、開発者の84%がAIツールを毎日使用し、コードの41%がAIで生成されるようになります。これらの人々は、あなたのウィキのサイドバーをナビゲートしているわけではありません。彼らはClaudeやCopilotに質問し、AIが彼らの代わりにあなたのドキュメントを読んでいるのです。

この意味は言い過ぎではありません。最も頻繁にドキュメントを読む人は、もはやブラウザーのタブを開いている人ではありません。検索を呼び出す言語モデルなのです。そしてそのモデルには、ページを目を細めて「うーん、これは古そうだ」と考える能力はありません。

GitBookはこのことにいち早く気づき、State of Docs 2026 reportと機械可読フォーマットへのプッシュで対応しました。GitBookはまた、skill.mdという、AIエージェントに特化した製品情報の構造化規約を発表しました。Googleはさらに、Gemini API Docs MCPを開発しました。これは、モデルコンテキストプロトコルを介して、コーディングエージェントを最新のドキュメントに接続するものです。その理由は明確で、エージェントが古いコードを生成するのは、彼らのトレーニングデータに期限があるからです。MCPの修正により、彼らの評価合格率は96.3%になりました。

というわけで、最初のトレンドは決まりました。AIは主要なリーダーです。これを後から追加する機能ではなく、コアとなる設計上の制約として扱うプラットフォームが構造的に優位に立つでしょう。

2.鮮度と信頼のメタデータが必須に

Anthropicは2025年12月に81,000人のクロードユーザーにインタビューを行い、2026年3月に結果を発表しました。AIユーザーを対象とした定性調査としては過去最大規模（159カ国、70言語）。最も懸念される点は？信頼性の低さ。回答者の27％が最大の懸念として挙げ、そのうちの79％が実際に経験したことがあるとのこと。

この数字は、すべてのドキュメンテーション・チームを夜も眠らせないはずです。

AIの回答が信頼できない場合、問題は常にモデルにあるわけではありません。多くの場合、モデルは古くなったドキュメントで見つけたことを忠実に再現しているのです。モデルが幻覚を見たのではありません。あなたのドキュメントが間違っていて、誰もそれを指摘しなかっただけなのです。

Stack Overflowのデータは、別の角度からこれを補強しています：81%の開発者は、来年にはAIがコードを文書化する方法にもっと統合されることを期待しています。ユーザーの81%がドキュメントをAIに渡しており、AIのユーザーの27%が信頼性の低さが最大の問題であると回答している場合、いくら迅速なエンジニアリングを行っても解決できない信頼性の問題があります。解決策はソースにあります。

これが、鮮度メタデータが重要な理由です。最終編集日」のタイムスタンプではありません（タイムスタンプは、コンテンツがまだ正確かどうかではなく、誰かがいつファイルを触ったか教えてくれます）。本当の鮮度：レビュー状況、リンクの健全性、翻訳の整合性、読者シグナル、コンテンツドリフトの検出。機械が読み取り、文書が引用しても安全かどうかを判断するために使用できるメタデータ。

私はシンプルなフレーミングに戻ってきます。あなたの文書にはクレジットスコアが必要です。タイムスタンプではありません。クレジットスコアです。(私たちはRasepiの鮮度スコアリングシステムを使ってまさにこれを構築してきました。）

3.翻訳は "プロジェクト "から "パイプライン "へ

DeepLは、2月に「グローバル企業が見逃せない6つの翻訳変革」という記事を発表しました。彼らの主張：翻訳は、四半期ごとに行うバッチプロジェクトではなく、継続的な運営課題になりつつあります。

これは、私が見ているすべてのものと一致しています。

昔のモデルは単純でした。英語で執筆。予算があれば、翻訳者を雇うか、翻訳サービスを利用します。翻訳が戻ってきたらアップロード。次回まで完了。問題は、製品が毎週出荷され、ドキュメントが常に更新されている場合、「次回」がどんどん早くやってくるということです。ドイツ語版がレビューから戻ってくるまでに、英語のソースはすでに2回変更されています。

DeepL独自のカスタマイズ・ハブでは、用語集、スタイル・ルール、および形式設定を提供しています。しかし、これらのツールがドキュメント・プラットフォームの外部にある場合、エディタ、エクスポート、翻訳、レビュー、再インポート、繰り返しという翻訳ツールチェーンを管理することになります。すべてのステップは、ドリフトのチャンスです。

Notionにはネイティブの多言語サポートはありません。Confluenceはマーケットプレイスのプラグインを通してそれを提供しています。GitBook 2025年8月に自動翻訳を追加は、ステップですが、ページレベルで動作します。

本当のシフトはページレベルからブロックレベルへの移行です。段落レベルで翻訳を追跡する場合、実際に変更された部分のみを再翻訳します。典型的な編集では、40の段落のうち2つの段落にしか触れません。これは翻訳作業を94％減らすことになります。(これがラセピのコアとなる翻訳アーキテクチャであり、正直なところ、私がこの製品で最も誇りに思っている点です。しかし、私たちのことはさておいても、業界の方向性は明確です。継続的、漸進的、埋め込み型の翻訳が、今後の方向性です)。

4.AIエージェントが必要とするのは、Wikiページではなく、構造化されたコンテンツ

これは、Notionが2月にCustom Agentsを発表したときに、私の中で結晶化しました。早期アクセス中に構築されたエージェントは21,000。ナレッジベースからの質問に答えたり、タスクをルーティングしたり、ステータスレポートをまとめたりするエージェントです。Rampだけでも300以上のエージェントがいます。

アトラシアンも同じような方向性です。Rovo AI in Confluence は、アトラシアンとサードパーティのアプリ全体からコンテキストを引き出し、コンテンツを生成します。彼らの売りは"チームの既存業務に基づいた、コンテキストリッチで高品質なコンテンツ"

そして Anthropic は、複数の AI エージェントが複雑なタスクを自律的に調整するクロードコードのエージェントチームを出荷しました。Opus 4.6は、8針1M MRCRベンチマークで76%のスコア（前モデルの18.5%から上昇）を記録しており、巨大な文書セットの奥深くに埋もれた情報を、見失うことなく実際に検索できることを意味します。

3社ともドキュメントを消費するエージェントを開発しています。いずれもソースの品質の問題は解決していません。

Notion のカスタムエージェントのドキュメントでは、エージェントが信頼できないコンテンツを読み込む際の prompt injection risk を明確に認めています。アトラシアンの Rovo は Confluence 内で見つけたものは何でも取得します。そのコンテンツが 3 ヶ月前のものであっても、Rovo は知りません。とにかくそれを基に構築します。

エージェントが確実に動作するためには、テキストのページ以上のものが必要です。安定した識別子、明示的な鮮度シグナル、明確な分類メタデータ、"これは最新でレビュー済み "と "これは存在するが1年間誰も触っていない "を区別する機能を持つ、構造化されたコンテンツが必要です。Wikiページはそれを提供しません。信頼できるメタデータを持つ構造化されたブロックレベルのコンテンツがそれを提供します。

5.オープンソースとセルフホスティングの復活

最後の1つは、1つの発表というよりも、データに裏打ちされた直感に近いものです。

GitBookは2024年後半に公開ドキュメントをオープンソース化し、OSSファンドを立ち上げました。その理由は、オープンソース・プロジェクトには無料で高品質なドキュメント・ツールを提供する価値があるからです。しかし、この動きはより広範な何かを示唆しています。

Notionはクラウド・オンリー。セルフホスト型のオプションはありません。Confluence データセンターは存在しますが、ライセンスが必要です。ドキュメントプラットフォームが最も機密性の高い業務知識（インシデントプレイブック、コンプライアンス手順、アーキテクチャの決定）を保持している場合、「誰がこのデータを管理するのか」という疑問は抽象的なものではありません。

Anthropicの2月の投稿"クロードは考える空間"は、信頼とビジネスモデルについて興味深い主張をしています。彼らの主張の核心は、広告インセンティブは本当に役に立つAIアシスタントとは相容れないということです。彼らは、ユーザーがツールを信頼できるように、広告がないことを選択しました。

私は、ドキュメント・プラットフォームにも類似点があると考えています。ドキュメント・システムがクローズド・ソースでクラウド・オンリーであれば、AIにフィードされる内容を検証することはできません。鮮度計算を監査することもできません。データの管理もできません。ナレッジベースの上にAIアシスタントを導入しているチーム（そして、ますます誰もがそうなってきています）にとって、監査可能性は重要です。

これは、オープンソースが道徳的に優れているという極論ではありません。クローズドソースの製品は絶対に信頼できます。しかし、社内のドキュメントの上にAIを活用したワークフローを構築する場合、システムを検査し、検証する能力は実用的な利点です。私たちにとって、ラセピのMITライセンスは後付けではありません。ドキュメンテーションのインフラは監査可能であるべきだ、という同じ論理に根ざした設計上の決定でした。

この5つのトレンドが意味するもの

個別に見れば、これらのトレンドはそれぞれ管理可能です。AIがドキュメントを読む？では、機械可読のメタデータを追加しましょう。鮮度が重要？わかりました。翻訳には継続性が必要？もちろん、DeepLを統合してください。エージェントに構造が必要？コンテンツ・モデルを改善してください。主権が重要ですか?素晴らしい、セルフホストオプションを提供してください。

しかし、これらを総合すると、現在ほとんどのチームが使用しているものとは根本的に異なるプラットフォームが見えてきます。

そのギャップはアーキテクチャにあります。これらは、ボルトオンで追加できる5つの機能ではありません。基盤に組み込むべき5つの前提なのです。コンテンツの保存方法（ページレベルではなくブロックレベル）。信頼のモデル化方法（タイムスタンプではなく、鮮度スコア）。翻訳の仕組み（インクリメンタル、埋め込み、段落ごと）。AIエージェントがコンテンツにアクセスする方法（ページスクレイプではなく、メタデータを含む構造化API）。データの管理方法（オープン、監査可能、セルフホスティング可能）。

これら5つすべてを同時に設計した確立されたプラットフォームはありません。少しずつ追加しているところもあります。GitBookはAIの可読性の面で最も早く進んでいます。Notionはエージェントインフラストラクチャを構築しています。アトラシアンはエンタープライズ向けのディストリビューションを持っています。

しかし、初日からこの5つすべてをデザインするのは難しいでしょう。それが、地盤が揺らいだときに新しく始める利点です。

偏見であることは自覚しています。私たちがラセピを構築したのは、これらのトレンドが収束していくのを目の当たりにし、最初からこれらすべてを想定したプラットフォームが欲しかったからです。ブロックレベルの翻訳、強制期限切れ、鮮度スコアリング、構造化されたAI対応コンテンツ、オープンソース。これがプロジェクト全体のテーマです。

しかし、仮に私たちが存在しなかったとしても、2026年の第1四半期に起こったことを素直に読めば、同じ方向に向かうと思います。ドキュメンテーションはインフラになりつつあります。そして、インフラストラクチャーはウィキページとは異なる要求を持っています。

このことを最初に理解したチームは、単にドキュメントが良くなるだけではありません。より信頼できるAIエージェント、より低い翻訳コスト、より少ないコンプライアンスサプライズ、そして長期にわたって実際に信頼され続けるナレッジベースを手に入れることができるのです。

これが2026年のドキュメントの姿です。問題は、これらのトレンドが本物かどうかではありません。御社のプラットフォームがこのようなトレンドのために設計されているかどうかです。

5つのトレンド。1つのアーキテクチャ上の質問：あなたのドキュメンテーション・プラットフォームは2026年を想定して設計されていますか？

ソースGitBook AI docs data report, GitBook State of Docs 2026, GitBook skill.md, Google Gemini API Docs MCP, Stack Overflow 2024 Developer Survey, GitHub 2024 developer survey, Index.dev developer productivity statistics, Anthropic "What 81,000 People Want from AI", Anthropic "Claude is a space to think", Claude Opus 4.6, Notion Custom Agents, Atlassian Rovo in Confluence, DeepL "6 Translation Transformations", DeepL Customization Hub, GitBook open source documentation, GitBook auto-translate..

開発者ではなく、ビルダー：クロードはどのようにあなたのドキュメントの対象者を変えたのか

2026-04-02T00:00:00Z

今、どこかで、あなたのAPIを統合している人がいます。彼らはあなたのドキュメントサイトにはいません。あなたのスタートガイドを開いていません。彼らはあなたのインタラクティブな遊び場や、入念にデザインされたサイドバーナビゲーションを見たことがありません。

彼らはClaudeに座っています。あるいはCopilot。あるいはカーソル。彼らは、「アプリルーターを使って、Stripeの課金APIをNext.jsアプリに統合する」_ などと入力し、動作するコードが戻ってくるのを待ちます。AIが代わりにドキュメントを読みます。関連するエンドポイントを見つけ、認証フローを理解し、適切なSDKメソッドを選び、実装を生成します。

2週間前、ザンクトガレンで開催されたStart Summit Hackathonで、私はこれがリアルタイムで起こるのを見ました。私はCSの学生グループと、初期段階のスタートアップの創業者たちと、新しいAPIにどのようにアプローチしているかについて話していました。問題をAIに貼り付け、コードを返してもらい、それを繰り返すというものです。ドキュメントを読んだのかと私が尋ねると、学生の一人が笑いました。「なぜ私が？クロードが読んでくれるから」。

その人はあなたのサイトを見たことがありません。その人はあなたのサイトを見たことがありません。そして、このようにソフトウェアが構築されることが多くなってきています。

コアシフト

ドキュメントを読む人間と、構築者に代わってドキュメントを読むAIアシスタントです。ほとんどのドキュメントは人間専用に最適化されています。AIはすでに支配的な読者です。

これは、下流のすべてを変えます：

AIが古くなったコンテンツを提供した場合、構築者はその問題を検知する手段がありません。ダメージは静かに拡大します。
プロダクトマネージャー、デザイナー、アナリストは、AIアシスタントを通じてソフトウェアを出荷しています。
きれいなマークダウン、自己完結型のブロック、明示的なメタデータは、AIがあなたの製品を正確に表現することを可能にします。
人間の読者は物語を必要とします。AIの仲介者は、構造化され、解析可能な仕様を必要とします。あなたは両方に対応する必要があります。

この記事の残りの部分では、私たちがどのようにしてここまで来たのか、このことがDevRelにとって何を意味するのか、そしてあなたが今すぐにできることについて説明します。

誰も計画しなかった旅

長い間、開発者関係はよく理解された道をたどってきました。包括的なドキュメントを書きました。クイックスタートガイドを発行。カンファレンスでの講演。Stack Overflowで存在感を示しました。APIリファレンスを検索できるようにし、SDKをイディオムにし、エラーメッセージを親切にしました。

その道は、開発者があなたのコンテンツを読むことを前提としていました。あなたの構造をナビゲートしてください。手順を追って。

GitHubの2024年開発者調査によると、エンタープライズ開発者の97%がAIコーディングツールを使ったことがあることがわかりました。Stack Overflowの年次調査によると、全開発者の76%がAIツールを使用しているか、使用する予定であり、62%のプロフェッショナルが毎日積極的に使用しています。2026年までに、この数字は84%に上昇し、現在では全コードの41%がAIによって生成され、プロの開発者の51%が毎日AIツールを使用しています。この数字は減速していません。

新しい旅の形は異なります。誰かが自然言語で欲しいものを説明します。AIアシスタントがドキュメントを読み、関連するセクションを見つけ、統合を生成します。ビルダーは出力を確認し、プロンプトを改良し、フォローアップを求めるかもしれません。数時間ではなく、数分。

DevRelチームが何年もかけて完成させた、スタートアップファネル？それは回避されつつあります。それが悪いからではありません。エントリーポイントが移動しただけです。

2人のコンシューマー、1セットのドキュメント

ドキュメントは現在、2つの根本的に異なる読者を抱えています。

1つ目は人間の読者です。この人はまだ存在します。彼らは、アーキテクチャの決定、エッジケースのデバッグ、コンプライアンスレビュー、コンセプトの理解のために現れます。彼らが求めるのは、物語的な説明、よく整理された参考資料、トレードオフに関する明確な理由付けです。

2つ目は、AIの仲介者です。AIは構築者に代わってドキュメントを読みます。サイドバーなど気にしません。視覚的なデザインも評価しません。きれいなマークダウン、一貫した書式、曖昧さなく推論できる明確な仕様などです。

今日、ほとんどすべてのドキュメントサイトは、第一の読者だけに最適化されています。第二の読者は、すでに支配的な消費者です。

Jeremy Howardは、2024年に/llms.txt標準を提案したときに、この緊張を特定しました。彼の観察は的確でした：大規模な言語モデルはますますウェブサイトの情報に依存するようになっていますが、決定的な限界に直面しています。CODEBLOCK_0__のマークダウンファイルは、AIモデルに製品の構造化された概要と最も重要なリソースへのリンクを提供します。FastHTML、Anthropic自身のドキュメント、そしてプロジェクトの成長ディレクトリは、現在その1つを配布しています。

これは便利な慣習です。しかし、それはまた、より深い問題の徴候でもあります。本当の問題は形式ではありません。ほとんどのドキュメントは、機械による消費を念頭に置いて設計されていないということです。

ビルダーは手を抜いていません

ドキュメントを読まずにクロードを促す人を見て、彼らが手抜きをしていると結論づけたくなる誘惑があります。彼らはコードの中で何が起こっているのかを本当に理解していないのだと。彼らは開発者としては劣っていると。

私はこの会話を何度もしてきたので、それはたいてい間違いだとわかっています。

このような開発者の多くは、意図的に効率的な選択をしている上級エンジニアです。彼らはコードを理解し、実際に必要な3行を見つけるために4ページのドキュメントをナビゲートしたくないだけなのです。彼らは、AIアシスタントがそれらの行をスキャンするよりも速く抽出できることを学んだので、読み取りを委任するのです。(正直なところ、私自身もそうしています。正直なところ、私自身もそうしています)。

AnthropicはModel Context Protocolを構築したとき、このパターンを認識しました。MCPは現在、Claude、ChatGPT、VS Code、Cursorなどでサポートされています。MCPは、AIアシスタントが外部システムにアクセスし、コンテキストを引き出し、それに基づいて行動できるように明確に設計されています。仕様書では、「機能を強化し、エンドユーザー体験を向上させるデータソース、ツール、アプリのエコシステムへのアクセス」を提供すると説明されています。

よく読んでください。これはインフラストラクチャー言語であり、利便性言語ではありません。これらのツールを使用するビルダーは、仕事を避けているわけではありません。彼らは新しいレイヤーを通して作業しているのであり、あなたがそれを設計したかどうかにかかわらず、あなたのドキュメントはそのレイヤーの一部なのです。

これは数字が裏付けています。Claudeだけで、現在月間250億のAPIコールを処理し、159カ国に3000万人の月間アクティブユーザーを抱えています。フォーチュン100社の70%がクロードを使用しています。Menlo Venturesの調査によると、Anthropicはモデル使用率でエンタープライズAI市場シェアの32%を占め、OpenAIの25%を上回っています。HSBCの調査レポートでは、さらに高く、AIの総支出額の40%を占めています。これらは実験的なツールではありません。主要なインフラなのです。

開発者関係は異なる時代のために構築されました

もしあなたのDevRel戦略が2023年以前に設計されたものであれば、それは開発者がドキュメントを直接読む世界を想定して設計されたものです。その世界は消滅したわけではありませんが、開発者の増加するシェアにとって、もはや支配的なインタラクションパターンではありません。

このことは、いくつかの長年のDevRel活動の計算を変えることになります。

**開発者会議での45分のプレゼンテーションは、数百人の聴衆に届きます。よく構造化された/llms.txtファイルときれいな機械可読ドキュメントは、あなたの製品についてAIアシスタントに質問するすべてのビルダーに、いつでも継続的に届きます。講演は1回限りのイベントです。機械可読のドキュメントは複合的なものです。私はカンファレンスが無価値だと言っているわけではありません（私は文字通りカンファレンスから戻ったばかりです）。

スタートガイド. 古典的な5ステップのクイックスタートチュートリアルは、ますます形式的になっています。ビルダーはステップに従いません。彼らは欲しいものを説明し、AIが統合を生成することを期待します。もしAPIがマシンフレンドリーなフォーマットできちんと文書化されていれば、AIはチュートリアルよりも効率的に使い始めを処理します。チュートリアルが代わりにすべきことは、概念的な資料、つまり、なぜアプローチBではなくアプローチAを選ぶのかを説明することです。AIは実装を生成することができますが、トレードオフを説明することはできません。

**Stack Overflow.**彼ら自身の調査データによると、開発者の84%が技術文書を直接利用しており、そのうちの90%はAPIやSDKパッケージ内の文書に頼っています。しかし、それらのドキュメントにアクセスする方法は、ブラウザのタブではなく、AIレイヤーを介することが多くなっています。今でもStack Overflowに寄せられる質問は、難しいものになりがちです。エッジケース、プロダクションデバッグ、ニュアンスを必要とするもの。確かに貴重です。しかし、もはやボリュームはありません。

AIがあなたのドキュメントを読むとき、鮮度が重要になります。

ここが、ほとんどのチームが考えていない部分です。

人間がドキュメントのページを読むとき、彼らは判断を下すことができます。スクリーンショットが古そうだとか、一番下のコメントにプロセスが変わったと書いてあるとか。目を細めて、"これは時代遅れだ "と思うかもしれません。

AIアシスタントにはそれができません。テキストを読み、それを事実として処理し、完全な自信をもって答えを生成します。ドキュメントに非推奨のエンドポイントが記載されていれば、AIは喜んでそのエンドポイントとの統合を勧めます。ドキュメントが6ヶ月前に置き換えられたインフラを参照している場合、AIは古いセットアップを最新のものとして説明します。迷いはありません。

そして、これが想像以上に悪いことなのです：開発者の66%はすでに、AIツールの最大の問題は、"ほぼ正しいが、まったく正しくない "結果を出すことだと言っています。陳腐なドキュメントは、この問題に直接影響します。AIは幻覚を見ているのではありません。古いコンテンツを忠実に再現しているのであり、その違いをビルダーが見分ける方法はありません。

建設者はAIを信頼します。AIはドキュメントを信頼します。もし文書が古ければ、その信頼の連鎖は確信を持って間違った答えを出します。

これは常に問題でした。陳腐なコンテンツは常に人々を混乱させてきました。しかし、人間の読者がそれを発見できることがあったため、被害は抑えられました。AIの仲介者にはそれができません。AIは、疑う理由のない人々に、権威をもって、大規模にコンテンツを提供することによって、陳腐なコンテンツを増幅させるのです。

鮮度はもはやコンテンツの質の問題ではありません。ドキュメントに触れるすべてのAIワークフローの信頼性の問題なのです。

「開発者」という言葉は狭すぎる

2026年にソフトウェアを作っている人たちは、全員が開発者だと認識しているわけではありません。動くプロトタイプを作るためにクロードを促すデザイナーもいます。Cursorを使って社内ツールを出荷するプロダクトマネージャーもいます。データパイプラインを自然言語で記述し、エージェントに組み立てさせるデータアナリストもいます。Start Summitでは、ハッカソンチームの半数がプログラミングの素養が全くないメンバーで構成され、週末が終わる頃には実用的なソフトウェアを出荷していました。

Rampは有用な例です。このフィンテック企業は、2023年の評価額58億ドルから2025年後半には320億ドルになり、その過程で年換算収益が10億ドルを超えました。史上最も急成長した新興企業のひとつ。彼らのアプローチの一部として広く議論されているのは、プロダクトマネージャーがエンジニアリングバックログで待つのではなく、AIツールを使って直接機能を構築することです。RampのPMは仕様を書くだけではありません。彼らはコードを出荷します。実装はAIが行います。PMは意図を処理します。

近道ではありません。新しいオペレーティング・モデルであり、実験と見なすのが難しい規模で機能しています。

Anthropic自身の内部調査は、ここで明らかにしています。自社のエンジニア132人を対象に、Claudeをどのように使っているかを調査したところ(https://fortune.com/2025/12/02/how-anthropics-safety-first-approach-won-over-big-business-and-how-its-own-engineers-are-using-its-claude-ai/)、エンジニアは仕事の約60%にClaudeを使っていると答えました。最も一般的な用途は？既存のコードのデバッグ、コードベースの一部が何をしているかの理解、新しい機能の実装。エンジニアは、「複雑でなく、反復的で、コード品質が重要でない」作業をクロードに任せる傾向があると述べています。また、現在Claudeで行っている作業の27%は、以前は全く行っていなかったものだそうです。

Anthropicのチームです。モデルを構築した人々は、ドキュメントリーダー、コードベースナビゲーター、初稿作成ツールとして使用しています。他のみんなも同じことをしています。

Anthropicは、このペルソナを "ビルダー "と呼んでいます。彼らのツールは、プロのソフトウェアエンジニアだけでなく、作りたいものを説明できるすべての人のために設計されています。クロードが、MCPを介して、Figmaの設計からフルスタックのアプリケーションを足場組みすることができれば、「開発者」と「非開発者」の間の伝統的な境界線はなくなります。

このことは、ドキュメントを管理したり、開発者の体験を気にかけたりする人にとって、大きな意味を持ちます。読者は、もはや REST エンドポイントが何であるかを知っている人に限定されません。AIアシスタントがあなたの製品とやりとりする可能性のあるすべての人が含まれます。あなたのAPIを使って機能を出荷するRampのPM？おそらくあなたのドキュメントを直接読むことはないでしょう。彼らのAIエージェントは絶対に読むでしょう。

ドキュメンテーションの意味

もしドキュメントが人間の読者とAIの仲介者という2つの読者を対象にしているのであれば、その両方に対応する必要があります。当たり前のことです。実際には、ほとんど誰もやっていません。

私が実際に重要だと思うことは以下の通りです：

**もしあなたのAPIドキュメントが美しくレンダリングされたHTMLページで、それをLLMがスクレイピングして解析しなければならないのであれば、AIは必要以上に働いていることになります。レンダリングされたバージョンと一緒に生のOpenAPI仕様を出荷してください。きれいなマークダウンを出荷してください。AIにページレイアウトを解釈させることなく、仕様にアクセスできるようにしましょう。

**ページレベルの説明の代わりにブロックレベルの構造。彼らは関連するセクションを抽出します。明確な見出し、自己完結した段落、明示的なブロックレベルのセマンティクスを持つ文書は、文脈のためにページ全体を読む必要がある流れるような物語よりも、AIにとって劇的に有用です。

**この文書が最後に見直されたのはいつですか？これはまだ最新ですか？コンテンツにフラグはついていますか？これらのシグナルは、ウェブページ上の視覚的な手がかりとしてだけでなく、AIがアクセスできる形で存在する必要があります。鮮度スコア、有効期限切れステータス、レビュー日付、これらはAIがドキュメントをソースとして使用しても安全かどうかを判断するためのメタデータです。

**AIアシスタントが非推奨のエンドポイントに基づいた確信に満ちた回答をビルダーに提供する場合、その損害は404よりも深刻です。ビルダーはそれを基に構築します。それを出荷します。そして、本番で壊れ、誰かが数ヶ月前に更新されたはずのドキュメントにたどり着くまで、誰もその理由を知りません。AIが参照する可能性のあるすべての文書には、それがまだ最新であることを証明するメカニズムが必要です。(これは完全な開示ですが、まさに私たちがRasepiを構築して解決しようとしている問題です。ドキュメントブロックに強制的な有効期限を設定することで、古くなったコンテンツが隠れないようにします)。

はじめに: 現在のドキュメントを監査しましょう

ここまで読んで、「よし、でも実際に月曜日に何をすればいいんだろう」と思った方、今週チェックできる具体的なことを4つ紹介します。

1.AIを使ってドキュメントをテストする ClaudeやChatGPTを開き、現実的なシナリオであなたの製品を統合するよう依頼してください。社内の知識は使わないでください。AIが生成するものを見てください。それは正しいですか？最新ですか？正しいエンドポイント、正しいSDKバージョン、正しい認証フローを使用していますか？もしAIがそれを間違えているなら、それは今ビルダーが得ているものです。

2.2.コンテンツが古くなっていないかチェックしましょう。 最もアクセス数の多いドキュメントページを5つ選び、こう尋ねてください。それはまだ製品の現在の状態を説明していますか？あなたが自信を持って答えられないなら、AIも答えられません。これは、ほとんどのチームにとって、最も活用度の高い修正方法です。

**3.もし/llms.txtファイルを持っていないなら、作ってください。もしAPIリファレンスがレンダリングされたHTMLとしてしか利用できないのであれば、生のOpenAPI仕様をエクスポートしてアクセスできるようにしてください。もしあなたのドキュメントがきれいなマークダウンを出力しないCMSにあるのなら、それは今すぐ解決する価値のある問題です。

**4.コンテンツ管理システムのlast-reviewedフィールドのような単純なものでも、トラフィックの多いページには必須のレビューサイクルを設定します。これは、人間とAIの両方に、コンテンツが信頼できるかどうかのシグナルを与えます。ラセピのようなツールはブロックレベルで強制的に期限切れにすることでこれを自動化することができますが、手作業でも何もしないよりはマシです。

商品の表現方法の静かな変化

直接的に述べる価値のある、より広範な結果があります。

あなたのドキュメントは、もはや開発者のための参考マニュアルではありません。それは、AIアシスタントがあなたの製品を世界に表現するために使用する資料なのです。ビルダーがあなたの製品の使い方をクロードに尋ねるとき、クロードの答えは、あなたのドキュメントから見つけて解析できるものによって形作られます。

良いドキュメント、良い答え。時代遅れで、あいまいで、モデルが解析するのが難しいHTMLの中に閉じこめられている場合は？より悪い答えか、正しくない答えです。簡単なことです。

あなたの製品に関するAIの回答の質は、今やあなたの開発者エクスペリエンスの直接の代理人です。ほとんどの企業はまだそのように扱っていません。

先行しているStripe、Vercel、Cloudflare、Anthropicなどのチームは、AIの可読性を第一級の問題として扱っています。ドキュメントの書き方、構造化、メンテナンスの方法を形作る基本的な要件です。来期のバックログ項目にはなりません。

今クロードに座っているビルダーは、何を作りたいかを説明し、数分で動くコードを期待しています。彼らは二度とドキュメントサイトを訪れることはないかもしれません。しかし、彼らにサービスを提供するAIはそうします。常に。

そのAIが今、あなたの最も頻繁な読者なのです。問題は、あなたのドキュメントがそれに対応しているかどうかです。

2026年における最高の開発者エクスペリエンス戦略は、カンファレンスでの講演やクイックスタートガイドではありません。AIが正しく理解できるようにすることです。

*この記事は、一般に公開されている調査結果や製品ドキュメントを参照しています。統計は、GitHub's 2024 developer survey, Stack Overflow 2024 Developer Survey, Index.dev's 2026 developer productivity report, Incremys Claude statistics, Fortune's reporting on Anthropic から引用しています。/llms.txt仕様はllmstxt.orgで管理されています。モデルコンテキストプロトコルは modelcontextprotocol.io で文書化されています。

Rasepi 翻訳の実際の仕組みと、あなたのチームと同じように聞こえる理由

2026-03-31T00:00:00Z

Google翻訳や正直なところあらゆる翻訳ツールで文書を翻訳したことがある方なら、その結果をご存知でしょう。技術的には正しい。トーン的に間違っています。製品が突然違う名前で呼ばれたり。チーム内の略語が消えてしまいます。あなたの会社がインフォーマルを使っているところ、フォーマルな「あなた」、またはその逆。

アウトプットは翻訳されていますが、あなたのようには聞こえません。

それを解決するために、私はラセピの翻訳システムを作りました。"ドキュメントを翻訳できるか "ではなく、"実際に私たちのチームが書いたように聞こえるように翻訳できるか "です。

答えはイエスです。そして、プロの翻訳者チームを必要としません。

あなたのチームのように聞こえる翻訳](/ja/blog/img/natural-translations.svg)

##変更されたものだけが翻訳されます

ほとんどのドキュメントプラットフォームはページ全体を翻訳します。一つの文章を変えただけで、文書全体が再翻訳されるのです。すべての言語、すべての段落、それが変更されたかどうかに関係なく。

ラセピは違います。すべての段落を個別に追跡します。20セクションの文書の1セクションを編集すると、そのセクションだけが再翻訳されます。他の19のセクションは、すべての言語にわたって、まったくそのままです。

これは2つのことを意味します：

1.**翻訳コストは劇的に下がります。ほとんどの更新は、ページ全体ではなく、1つか2つのセクションに触れます。 2.**ドイツ語チームが先週翻訳を承認した場合、無関係な段落を英語で編集しても、承認されたテキストには影響しません。

すべての段落は一意のIDとコンテンツのフィンガープリントを持っているので、システムは何が変更されたかを知っています。フィンガープリントが変更されると、その特定の段落に再翻訳のフラグが立てられます。他には何もありません。

あなたの用語集、あなたの専門用語

ここからが面白くなります。

どの会社にも独自の語彙があります。「スプリントレビュー」は、ベルリンのチームが英語の用語を使っているため、ドイツ語のドキュメントでは「Sprint Review」のままかもしれません。あるいは、ミュンヘンのチームがドイツ語版を好むので、"Sprint-Überprüfung "になるかもしれません。「ナレッジベース」は「Wissensdatenbank」や「Knowledge Base」になるかもしれませんし、チーム内でまったく別の造語を使うかもしれません。

ラセピでは、言語ごとに用語集を作ることができます。基本的には用語とその承認された翻訳のリストです。段落が翻訳されると、まず用語集をチェックします。リスト内の全ての用語は、あなたが定義した通りに翻訳されます。毎回。すべてのドキュメントで。

用語集はラセピで直接管理できます：

用語の不一致に気づいたら、一つずつ用語を追加してください。
他のシステムから用語集を既に持っている場合、CSV**をインポートします。
外部の翻訳者や他のツールと共有するために用語集をエクスポートします。

用語集は言語ペアごとに機能します。英語からドイツ語への用語集は、英語からフランス語への用語集とは別のものです。同じ英語の用語でも、言語によって扱いが異なる場合があるためです。「スプリントレビュー」はドイツ語では英語のままですが、日本語では翻訳されるかもしれません。

用語集を更新すると、次にその言語に翻訳されたときに変更が反映されます。すべてを手動で再翻訳する必要はありません。次の自然な編集サイクルで反映されます。

スタイルルール: あなたが書いたような翻訳にするために

用語集は個々の単語を扱います。しかし、正しい用語が使われていても、翻訳がおかしいと感じることがあります。間違ったトーン間違った形式の日付。間違った区切り文字の数字間違った場所にある通貨記号。

それがスタイル・ルールです。

言語ごとに、翻訳の形を制御するルールのコレクションを設定することができます：

書式規則

これは、「明らかに英語から翻訳された」文書ではなく、「ネイティブの文書」と感じさせるための詳細です：

日付と時刻の書式。** ドイツ語では 24 時間時計、英語では AM/PM など。
数字の書式.** ドイツ語の小数点以下の区切りとしてのコンマ（3.14の代わりに3,14）、千のピリオド
句読点の規則。 学位の書式、引用符の様式、および他の地域慣習

あなたの会社の基準に合った規則を選んでください。ラセピは、その言語のすべての翻訳、すべての文書に適用します。

カスタム指示

ここが本当に強力になるところです。カスタム命令とは、翻訳エンジンにコンテンツの処理方法を指示する、平易な言語による命令です。あなたは通常の文章でそれを書き、エンジンはそれに従います。

いくつか例を挙げます：

親しみやすい文書にしたい会社には、「親しみやすく、外交的な口調で」*。
ドイツ語のプロフェッショナルなコミュニケーションには、「常に正式な『Sie』形を使用し、決して『du』を使用しない」*。
英語を話す読者が英国に住んでいる場合は、"色、組織、ライセンス "*イギリス英語のスペルを使用します。
ヨーロッパの慣習に合わせるために、数字の後に通貨記号を付けてください。
"APIエンドポイントを説明するときは、命令形を使用する "*直接的な印象を与える技術文書の場合

言語ごとに最大200のカスタム命令を追加できます。これらは、用語集や書式規則と一緒に機能し、翻訳エンジンは、すべての翻訳でそれらをすべて一緒に考慮します。

形式

ドイツ語には "du "と "Sie "があります。フランス語には "tu" と "vous" があります。日本語には複数の丁寧レベルがあります。明らかな形式的代名詞と形式的代名詞のない言語にも、重要な音調の違いがあります。

ラセピでは、各言語のフォーマルレベルを設定することができます。一度設定すれば、すべての翻訳パラグラフがそのトーンに一致します。もし、あなたの会社が、フランス語ではフォーマル（"vous"）に、ドイツ語ではインフォーマル（"du"）に読者に語りかけるのであれば、すべての翻訳がまさにそうなります。

すべてが連動します

重要なのは、用語集、書式規則、カスタム指示、形式設定のすべてが、すべての翻訳に同時に適用されることです。どれかを選ぶのではありません。すべて一度設定すれば、翻訳されるすべての段落が同じルールで処理されます。

その結果、ローカルチームの誰かが書いたような翻訳ができあがります。機械があなたの会社のことを何も知らずに翻訳した文章ではありません。

各言語は独自のコンテンツを持つことができます

これは、最も人々を驚かせる機能です。

ラセピでは、翻訳された文書はオリジナルのコピーではありません。各言語バージョンは、その言語にしか存在しないコンテンツを持つことができます。

**なぜこれが重要なのでしょうか？

市場によって必要なものが違うからです：

ドイツ語のドキュメントには、米国版には適用されないDSGVO（GDPR）準拠のセクションが必要かもしれません。
日本のチームには、誰も使っていないローカル・ツールの注意書きが必要かもしれません。
ブラジルのオフィスでは、地域の税制に関するコンテキストが必要になるかもしれません。

ほとんどの翻訳ツールでは、ある言語バージョンにコンテンツを追加すると、次に誰かが英語から再翻訳するときに上書きされてしまいます。チームはすぐにこのことに気づき、ローカルのコンテンツを追加するのを止めます。そして、NotionやSlackなどにシャドウ・ドキュメントを作成します。

ラセピでは、ユニークなコンテンツはその言語のものとしてフラグが立てられます。再翻訳によって上書きされることはありません。英語のソースが変わっても削除されることはありません。ドキュメントの自然な一部として、翻訳されたコンテンツと一緒に存在します。

構造についても同様です。英語版では箇条書きを使っているところを、日本語の翻訳者が番号付きリスト（日本語のテクニカルライティングでは一般的な慣例です）を好む場合、フォーマットを変更することができます。ラセピはその選択を将来のアップデートでも維持します。

どの言語版もファーストクラスの文書であり、読み取り専用のミラーではありません。

自動と人間: 共に働きます

ラセピは、機械翻訳か人間翻訳かの二者択一を迫ることはありません。両方をサポートし、その違いを知っています。

ある段落が機械翻訳され、ソースが変更されると、ラセピは自動的に再翻訳します。人間の介入は必要ありません。用語集とスタイルルールが一貫性を保ちます。

段落が人間の翻訳者によって手作業で編集された場合、文化的なニュアンスのために書き直されたり、機械では捉えられない文脈が追加されたりするかもしれませんが、ラセピはその作業を尊重します。ソースが変更された場合、システムはレビューが必要な段落としてフラグを立てますが、人間の編集を黙って上書きすることはありません。翻訳者はソースのどこが変わったかを見て、自分のバージョンをどのように更新するかを決めます。

つまり、翻訳品質は時間とともに向上します。機械翻訳が大部分を処理します。人間の翻訳者は、人間的なタッチが必要な段落に焦点を当てます。そして、どちらも相手の仕事を踏みにじることはありません。

2つのモード：常に最新の翻訳とオンデマンド翻訳

各言語について、翻訳を行うタイミングを選択できます：

**常に翻訳.**誰かがソースドキュメントを保存するたびに、変更された段落はすぐに再翻訳されます。読者が分刻みの正確さを期待する最も重要な言語に最適です。
変更された段落は、フラグが立てられますが、誰かが実際にその言語で文書を開くまでは翻訳されません。使用頻度の低い言語に最適です。誰も読まないコンテンツに無駄な翻訳コストをかけません。

どちらのモードも、同じ用語集、同じスタイルルール、同じ品質を使用します。唯一の違いはタイミングです。

実際のところ

あなたがロンドン、ミュンヘン、パリ、東京にチームを持つ会社を経営しているとします。ドキュメントは英語で書かれています。

ロンドンのプロダクトマネージャーがデプロイメントガイドを更新しました。新しいCI/CDステップに関するセクションが1つあります。

こうなります：

変更されたセクションは数秒以内に再翻訳されます。「スプリントレビュー "は "Sprint-Überprüfung "になります。フォーマルな "Sie "は、それがあなたのフォーマルな設定だからです。日付が24時間形式なのは、それがあなたの設定したルールだからです。直接的で命令的な口調を使う」という習慣的な指示が言い回しを形作っています。ミュンヘンチームが追加したDSGVOセクションは？そのままです。
同じセクションをすぐに再翻訳。"Vous "形式。フランス語の用語集を適用。数字の後に通貨記号を追加しました。その他の部分は、パリ支社が最後に確認したとおりになります。
**日本語（閲覧時に翻訳）.**変更されたセクションはstaleとしてフラグが立てられます。東京の誰かがドキュメントを開くと、その場で翻訳されます。その人のカスタム番号リスト書式は保持されます。ローカルツールノートはそのまま残ります。

1回の編集で3つの言語を更新。ドキュメントの再翻訳はゼロ。一貫した用語、一貫したトーンで、各チームのローカルな追加を尊重。

言語品質といえば

この翻訳エンジンは、ラズパイの Talk to Docs 機能と同じ DeepL です。ドキュメントに話しかけると、音声で回答を得ることができます。DeepLボイスが音声対話を処理するため、文章翻訳と同じ用語の一貫性、スタイルルール、言語品質が音声会話にも適用されます。用語集の用語やカスタム指示は、チームが読んでいても聞いていても正しく聞こえます。

お客様のチームと同じように聞こえる翻訳は、贅沢品ではありません。言語をまたいで事業を展開する企業にとって、翻訳こそが、信頼される文書と回避される文書の違いなのです。用語集、スタイルルール、カスタム指示、スマートな再翻訳、言語ごとのユニークなコンテンツがそれを可能にします。初日から自動的に。

あなたのドキュメントは、どの言語でもあなたのチームと同じように聞こえるべきです。機械的ではありません。別の会社のようでもなく。あなたのように。

多言語パブリッシングの実際を見る→

翻訳エンジンの内部：用語集、スタイルルール、スマート再翻訳

2026-03-31T00:00:00Z

以前のアーキテクチャの投稿](/ja/blog/how-plugin-guardrail-and-pipeline-systems-work/)では、プラグイン、アクションガード、パイプラインシステムを取り上げました。今回は、Rasepiを他のdocsプラットフォームと根本的に違うものにしていると私が考えている部分である、翻訳エンジンについて深く掘り下げます。

ページの代わりに段落を翻訳するという売り文句ではありません。実際のコードです。用語集がテナントごとにどのように解決されるのか、DeepLのスタイルルールとカスタム命令がどのようにすべての翻訳を形成するのか、コンテンツハッシュがどのように陳腐化を検出するのか、オーケストレータがどのブロックを再翻訳するかをどのように決定するのか。

翻訳エンジン: 用語集、スタイルルール、スマートな再翻訳](/ja/blog/img/translation-engine-deep-dive.svg)

翻訳パイプライン

ユーザーが文書を保存するとき、システムは単にすべてを再翻訳するわけではありません。かなり特殊なシーケンスを実行します：

1.TipTap JSONを個々のブロックに解析します。 2.どのブロックが実際に変更されたかを検出するために、コンテンツのハッシュを比較します。 3.変更されたブロックについて、テナントの用語集と言語ペアのスタイルルールリストを解決します。 4.テナント構成からスタイルルール、カスタム命令、形式を適用します。 5.変更されたブロックのみを DeepL に送信します。 6.翻訳ブロックの更新とコンテンツ・ハッシュの同期

各ステップは、独自のインタフェースを持つ独自のサービスです。どのステップも、別の翻訳プロバイダ、別のハッシュ・アルゴリズム、別の用語集ソースなど、別のものに交換できるため、これは重要です。

グロッサリ解決: テナントをスコープし、DeepLを同期します。

DeepL用語集には、ほとんどの人が知らない制約があります：**DeepL用語集は編集できません。DeepL 用語集を編集することはできません。変更すると、古い用語集が削除され、新しい用語集が作成されます。

Rasepiは、データベースを真実のソースとして扱い、DeepL用語集を使い捨ての実行時成果物として扱うことで、これを処理します。CODEBLOCK_16__エンティティはすべてをローカルに格納します：

コードブロック_0__

ユーザが用語集エントリを追加すると、例えば EN→DE の "Sprint Review" を "Sprint-Überprüfung" にマッピングすると、データベース・レコードが直ちに更新され、IsDirty が true に設定されます。DeepL 用語集はその時点では再作成されません。次に翻訳で実際に必要になったときに、DeepL 用語集は遅延的に再作成されます。

同期フロー

翻訳が呼び出されるたびに、用語集が解決されます：

コードブロック_1__

ここで注目すべきことが3つあります：

1.**翻訳が実際に必要な場合にのみ DeepL API を呼び出します。用語集エントリを一括編集しても、数十回の API 呼び出しがトリガされることはありません。 2.テナントの分離. クエリは EF グローバル・クエリ・フィルタを介して実行されるため、TenantGlossaries は自動的にスコープされます。テナントAの用語集エントリがテナントBの翻訳に漏れることはありません。 3.**DeepL は、とにかくこれを強制します。EN→DE 用語集を 1 つ、EN→FR 用語集を 1 つ、といった具合です。CODEBLOCK_20__ ペアはテナントごとに一意です。

用語集エントリ

個々のエントリは単なる用語のマッピングです：

コードブロック2

APIは完全なCRUDと一括管理のためのCSVインポート/エクスポートを提供します：

コードブロック_3__

CSVインポートは、既存の翻訳メモリシステムから移行するチームにとって非常に便利です。用語集をエクスポートしてクリーンアップし、Rasepiにインポートすると、次の翻訳実行時に新しい用語集が自動的に使用されます。

スタイルルール、カスタム命令、形式

用語集は専門用語を扱います。しかし、用語集はその半分に過ぎません。正しい言葉を使っていても、翻訳が誤って聞こえることがあります。語調の間違い、日付書式の間違い、句読点の打ち方の間違い。

DeepL の スタイル・ルール API (v3) は、これを解決します。2 種類のコントロールを組み合わせた再利用可能なスタイル・ルール・リストを作成できます：

1.構成ルール、日付、時刻、句読点、数値などの事前定義されたフォーマット規則 2.カスタム命令、トーン、言い回し、およびドメイン固有の慣習を形成するフリーテキスト命令

ラセピは、テナントごと、ターゲット言語ごとにこれらを作成し、管理します。CODEBLOCK_21__エンティティは、DeepLのstyle_idを、テナントの設定されたルールとカスタム命令と一緒に保存します：

コードブロック_4__。

スタイル・ルール・リストの作成

管理者がドイツ語の翻訳ルールを設定すると、RasepiはDeepLのv3 APIを呼び出してスタイルルールリストを作成します。以下はその様子です：

コードブロック_5__

用語集とは異なり、DeepLのスタイルルールリストは変更可能です。構成されたルールは PUT /v3/style_rules/{style_id}/configured_rules で置換でき、カスタム命令は個別に追加、更新、または削除できます。反復的な絞り込みに最適です。

構成されたルールはどのように見えますか？

設定されたルールは、言語や会社の好みによって異なる書式規則をカバーします。以下のようなものです：

__codeblock_6__のようなものです。

これらは些細なことのように聞こえますが、すぐに複雑になります。AM/PM時間フォーマットとピリオドで区切られた小数を使うドイツ語の文書は、ドイツ語の読者には「英語から翻訳された」としか読めません。すべてのドイツ語翻訳でuse_24_hour_clockとuse_commaを小数点区切り文字に設定すると、そのようなことはすぐになくなります。

カスタム命令: これが本当の力です

カスタム命令は、スタイル・ルール・リストごとに最大 200 個、それぞれ最大 300 文字のフリーテキスト命令です。基本的に、DeepL に翻訳をどのように作成するかを平易な言葉で指示します：

codeblock_7__

テナントからの実際の例：

CODEBLOCK_26__親しみやすいドキュメントを求める新興企業向け
CODEBLOCK_27__ドイツの法律事務所向け
"Translate 'deployment' as 'Bereitstellung', never 'Deployment'"単純な用語集のマッピングだけでなく、文脈に依存した取り扱いが必要な用語のための__CODEBLOCK_28__。
CODEBLOCK_29__ 英国を拠点とする企業で英語の異言語間の翻訳を行う場合
ヨーロッパの慣例に合わせるための"Put currency symbols after the numeric amount"。

カスタム命令は、用語集エントリに収まらないドメイン固有の慣習に対して非常に強力です。用語集は1つの用語を別の用語にマッピングします。カスタム命令では、"APIドキュメントを翻訳するときは、受動態の代わりに命令形を使いなさい "と言うことができます。これはまったく異なる種類のコントロールです。

形式

DeepLのformalityパラメータ (default、_more、less、prefer_more、prefer_less) は、スタイル・ルールと並んで、別のコントロールとして引き続き使用できます。ドイツ語の "du "と "Sie"、フランス語の "tu "と "vous"、日本語のポライトネス・レベル。これらはTenantLanguageConfigによってテナント言語ごとに設定されます：

コードブロック8

形式、スタイルルール、用語集はすべて合成されます。1つの翻訳呼び出しで3つすべてを実行できます：

コードブロック_9__

ここで注目すべきことが2つあります：

1.1. context パラメータ。翻訳品質を向上させるために、隣接するブロックをコンテキストとして渡します。DeepL は、曖昧さを解決するためにこれを使用しますが、翻訳や請求は行いません。周囲のコンテキストが生物学のドキュメントである場合とスプレッドシートのマニュアルである場合では、"セル" に関する段落の翻訳が異なります。 2.2. モデルの選択. style_id または custom_instructions を含む要求はすべて、自動的に DeepL の quality_optimized モデルを使用します。これは最高品質の階層です。これらを latency_optimized と組み合わせることはできませんが、これは DeepL による意図的な制約です。スタイルのカスタマイズにはフル・モデルが必要です。

これが想像以上に重要な理由

ドイツ語で社内文書を作成する企業が、非公式な「du」を使用していて、翻訳されたセクションで突然正式な「Sie」に切り替わるとします。よく言えば一貫性がなく、悪く言えばプロらしくありません。形式がそれを処理します。しかし、ドイツのオフィスでは24時間制を採用しているのに、AM/PMのタイムスタンプを使っていたり、通貨記号を数字の後ではなく、前に置いていたりする文書は、形式だけでは捕らえられません。

これら（スタイルルール、カスタム命令、形式、用語集）を重ねることで、あなたのチームの誰かが書いたような翻訳ができあがります。あなたの会社の存在を知らない機械が出力したようなものではありません。

DeepLサービス層

すべてのDeepL通信は、IDeepLServiceを経由します。これは、公式の DeepL .NET SDK をラップし、スタイル・ルールの v3 API 呼び出しを処理します：

コードブロック_10__

この実装は、言語コードの正規化を処理します。DeepL では、en の代わりに EN-US または EN-GB が、pt の代わりに PT-PT または PT-BR が必要です：

CODEBLOCK_11__

バッチ翻訳では、50 項目のチャンキングを使用して、DeepL の API の制限内でスループットを最大化します：

コードブロック_12__

ドキュメント全体ではなく、古いブロックのみを送信するため、1つの編集の典型的な翻訳バッチには、40以上のブロックではなく、1～3ブロックが含まれます。94%のコスト削減はここから生まれています。

翻訳オーケストレーター

CODEBLOCK_50__は、ソース文書が変更されたときに各ブロックをどうするかを決定します。決定ツリーを見てみましょう：

コードブロック_13__

重要なビットです：**人が編集したブロックが自動的に上書きされることはありません。**翻訳者が手動でブロックを調整した場合、たとえば文化的な背景を追加したり、わかりやすく言い換えたりした場合、システムはその作業を尊重します。翻訳者が手作業でブロックを調整した場合、例えば文化的な文脈を追加したり、わかりやすい表現に変更したりした場合、システムはその作業を尊重します。

CODEBLOCK_51__が有効な機械翻訳ブロックは直ちに再翻訳されます。CODEBLOCK_52__が有効な機械翻訳ブロックは、staleとマークされ、誰かが実際にその言語でドキュメントを開いたときに翻訳されます。

翻訳トリガー: 翻訳が行われるタイミング

各言語にはタイミングを制御するTranslationTriggerがあります：

コードブロック_14__

CODEBLOCK_54__は、翻訳をすぐに最新の状態にしたい優先度の高い言語に便利です。例えば、パリに大きなオフィスがある会社のフランス語。ミュンヘンに本社がある会社のドイツ語。

TranslateOnFirstVisitは、時々必要になるけれども、APIコストをかけてまで常に最新の状態に保つ価値がない言語に便利です。誰かがその言語でドキュメントを開くと、古くなったブロックがその場で翻訳されます。

どちらのモードでも、同じ用語集解像度、同じ形式設定、同じコンテンツハッシュを使用します。唯一の違いはタイミングです。

独自のコンテンツと構造の適応

このアーキテクチャは、単なる翻訳にとどまりません。

ドイツ語の翻訳者が英語には存在しないDSGVOコンプライアンスセクションを追加する場合、ドイツ語版では新しいブロックとして追加されます。そのブロックにはSourceBlockIdはなく、独自のコンテンツとしてフラグが立てられます。翻訳元がないため、システムが再翻訳に回すことはありません。ドイツ語にしか存在しないからです。

日本語の翻訳者が箇条書きリストを番号付きリストに変更した場合（日本語のテクニカルライティングでは一般的な慣習です）、このブロックのIsStructureAdaptedフラグによって、将来の再翻訳サイクルでもこのフラグが維持されます：

コードブロック_15__

CODEBLOCK_58__フラグは、コードブロック、URL、製品名、数学的表記など、そのままコピーされるべきコンテンツを扱います。翻訳プロバイダはこれらを完全にスキップします。

まとめ

それでは、全体の流れを見ていきましょう。ロンドンのユーザが英語のソース文書の段落を編集し、ミュンヘンのオフィスではドイツ語がAlwaysTranslateに設定されています：

1.User saves. TipTapがAPIにJSONを送信します。 2.**ブロック抽出と変更検出。CreateBlocksFromDocumentAsyncはJSONを解析し、コンテンツ・ハッシュを再計算し、新旧のハッシュを比較して、実際に変更されたブロックを特定します。 3.**ドイツ語のEntryTranslationを見つけ、ドイツ語のブロックをチェックします。機械翻訳であり、ロックされておらず、人間が編集したものでもないので、再翻訳の対象です。 4.**CODEBLOCK_62__で用語集IDを解決し、GetOrSyncStyleRuleListAsync("de")でスタイル規則を解決し、形式を "more"(正式には "Sie")に設定し、曖昧性解消の文脈として隣接するブロックを渡します。 5.**単一ブロックは、用語集ID、スタイルID、形式、およびコンテキストで送信されます。 6.**翻訳されたコンテンツが格納され、SourceContentHashが同期され、ステータスがUpToDateに設定されます。40以上のブロックの代わりに1つのブロックが翻訳されました。残りの39ブロックは？そのままです。

一方、あなたの東京オフィスは日本語がTranslateOnFirstVisitに設定されています。同じ編集で、日本語の翻訳ブロックはStaleとマークされます。東京の誰かが文書を開くと、ステップ5～9がその場で行われます。その構造適応（番号付きリスト）は保存されます。そのユニークなブロックはそのままです。

翻訳エンジンはラセピの中で最も目に見える価値を提供する部分だと思います。あなたの専門用語を使い、あなたの書式規則に従い、あなたのカスタム指示に従い、あなたの語調に合わせ、あなたの翻訳者の仕事を尊重し、全文再翻訳の何分の一かのコストで翻訳します。このアーキテクチャは、そのすべてを自動化し、人間が翻訳を引き継ぎたいときには邪魔になりません。

文書による翻訳と同じDeepLエンジンは、DeepL Voiceが音声インタラクションを処理する会話型ドキュメントインターフェイスであるTalk to Docsにも対応しています。同じ用語集、同じスタイルルール、同じ形式、同じ一貫性。チームがドキュメントを読む場合も、ドキュメントと会話する場合も、言語の品質は同じです。

Explore the translation API →

同じドキュメントのコピーを5部保持することをやめましょう

2026-03-31T00:00:00Z

今すぐ会社のwikiを開き、"onboarding "と検索してください。いくつの結果が得られますか？

グローバル企業であれば、1つではないと思います。おそらくこんな感じでしょう：

コードブロック_0__
コードブロック_1
コードブロック2
コードブロック3
コードブロック4

5つの文書。どれもほぼ同じ内容。すべて微妙に異なる。すべて異なる人が異なるスケジュールで管理。あるものは最新のもの、あるものは3ヶ月遅れ、あるものはもう誰もよくわからないもの。

これは、ドキュメント・プラットフォームが多言語コンテンツを適切に扱えない場合に起こることです。結局、市場ごとに文書全体をコピーすることになり、それぞれのコピーは徐々に他のものから離れていきます。

1つのドキュメント、すべての言語](/ja/blog/img/one-document-all-languages.svg)

コピー＆ローカライズの罠

最初は何の罪もありません。あなたは英語の素晴らしいオンボーディングガイドを持っています。ベルリン支社はそれをドイツ語で必要としているので、誰かがそれをコピーし、翻訳し、ドイツ特有の部分を追加します：DSGVOのトレーニング、Betriebsratの情報、地域の健康保険加入などです。

次に東京でも必要です。またコピー。翻訳。日本特有のものを追加：ハンコの登録、定期券の手続き、オフィスでのマナーガイド。

次はサンパウロ。これも同じ。コピーし、翻訳し、CLTの要件、食事券、税金に関する現地コンテンツを追加。

これで4つの書類ができました。英語のオリジナルは定期的に更新されます。ドイツ語版は前四半期に更新されました。日本語版は...田中さんが10月に更新したと思われる人がいます。ブラジル版は契約社員が作成したもので、その契約社員は退職し、それ以来誰も手をつけていません。

**そしてそのどれもが、共有コンテンツ（どこでも同じもの）とローカルコンテンツ（その市場特有のもの）を含んでいます。しかし、プラットフォームはその違いを知りません。すべてはページ上のテキストに過ぎないのです。

そのため、誰かが英語版のセキュリティポリシーのセクションを更新しても、他の4つのセクションは更新されません。さらに悪いことに、誰かがドイツ語の方を更新して、日本語の方は更新しないということもあります。こうして、同じ会社のポリシーについて、微妙に異なることが書かれた5つの文書ができあがります。

本当の問題：共有コンテンツとローカルコンテンツが混在していること

実は、これらのドキュメントのほとんどは70～80％同じなのです。オンボーディングの手順、ツールのセットアップ、セキュリティポリシー、会社の価値観のセクション、「連絡先」リスト。ベルリンにいても、東京にいても、サンパウロにいても、すべて同じです。

ローカルな内容は、ドキュメントの20～30％程度です。特定のコンプライアンス要件、現地の福利厚生、現地のプロセス、そのオフィスのチーム連絡先などです。

しかし、すべてが言語ごとに1つの大きなフラットなドキュメントにある場合、どの部分が共有され、どの部分がローカルなのかを見分ける方法がありません。共有コンテンツの更新は、すべてのコピーを手作業でチェックし、更新することを意味します。それを一貫して行う人はいません。そのため、コピーが流れてしまうのです。

1つのドキュメント。それだけ。

ラセピでは、オンボーディングガイドは1つのドキュメントです。言語ごとに1つではありません。一つです。

共有コンテンツ、つまりどこでも同じ70～80％は英語で一度書かれ、チームが使うすべての言語に自動的に翻訳されます。誰かが英語のセキュリティポリシーのセクションを更新すると、数秒以内にドイツ語、日本語、ポルトガル語、フランス語に再翻訳されます。手動でコピーする必要はありません。誰かが他のバージョンを更新する必要があります。

ローカルコンテンツはそれぞれの言語バージョンに存在します。DSGVOのトレーニングセクションはドイツ語版のみに存在します。ハンコプロセスは日本語版のみ。CLTの要件はポルトガル語版にのみ存在します。これらのセクションは独自のコンテンツとしてフラグが立てられ、その言語に属し、再翻訳によって上書きされることはありません。

この仕組みについては、ラセピ翻訳の仕組みで詳しく説明しています。簡単に説明しますと、各段落は独自のアイデンティティを持っています。共有された段落は翻訳され、追跡されます。独自の段落はその言語に属し、それ以外には何も触れません。

結果は？ウィキで "onboarding "を検索すると、1つの結果が返されます。"Onboarding "だけです。英語で開くと、すべての共有コンテンツを含む英語版が表示されます。ドイツ語で開くと、同じ共有コンテンツがドイツ語で表示され、ドイツ固有のセクションも表示されます。日本語で開くと、同じ共有コンテンツが日本語で表示され、日本固有のセクションも表示されます。

1つのドキュメント。5つではありません。5つの文書が別々のスピードでゆっくりと腐っていくのではありません。

これで実際に変わること

これは単に整理整頓されただけではありません。オフィス間のドキュメントの連携が根本的に変わるのです。

アップデートが実際に全員に届きます

オンボーディングガイドの共有部分を更新すると、すべての言語で更新されます。最終的にではなく、誰かがそれを行うことを思い出した後でもありません。自動的に更新されます。あなたが変更した段落は再翻訳されます。それ以外はすべて元のままです。

つまり、東京オフィスはロンドンオフィスと同じ会社規定を読むことになります。誰も更新しなかった半年前のバージョンではありません。

ローカルチームがローカルコンテンツを所有

ミュンヘンのチームは、次の英語のアップデートで消されることを心配することなく、地域のジム割引についてのセクションを追加することができます。彼らのユニークなコンテンツは彼らのものです。英語版のソースが変更されても、ドイツ語版にはそのまま残ります。

他のオフィスも同じです。ローカルコンテンツは純粋にローカルなものです。共有コンテンツに干渉することもなく、共有コンテンツに干渉されることもありません。

新入社員は正しい情報を入手

サンパウロの新入社員が入社ガイドを開くと、必要な情報がすべて表示されます。共有セクション（ツール、セキュリティ、価値観）はポルトガル語です。ブラジルに特化したセクション（CLT、税務書類、食事券）はすぐそばにあります。1つの文書で、すべてが彼らの言語で、不足はなく、時代遅れもありません。

他の3つのオフィスに異なるローカルセクションがあることを知る必要はありません。彼らは自分たちのバージョンを見るだけです。クリーンで完全。

ページ数の減少

これは単純な計算です。50の重要な文書があり、コピー＆ローカライズのアプローチで5つの言語で管理すると、250の文書があります。ラセピでは50です。それぞれの言語版は、共通のコンテンツを共有し、独自のローカルセクションを維持します。

250の文書と50の文書。200ページ分のメンテナンスのオーバーヘッドが消えます。

#オンボーディングだけではありません

すべてのグローバル企業がこの問題を抱えているため、オンボーディングは明らかな例です。しかし、どこでも同じパターンが見られます：

デプロイメントガイド.** コアステップは同じですが、ベルリンのチームはローカルのステージングサーバーを使用し、東京では承認プロセスが異なります。
ヨーロッパのGDPRセクション、ブラジルのLGPD、日本のAPPI。すべて同じ文書で、それぞれが関連するところだけ登場します。
育児休暇制度は国によって異なります。会社の価値観はどこでも同じです。
顧客向けヘルプ文書. 製品はどこでも同じように機能しますが、支払い方法、サポート時間、地域の規制は異なります。

これらの文書は、ほとんどの企業が市場ごとに別個のコピーとして管理しています。そして、その1つ1つが、共有されたローカルな内容を持つ1つの文書になる可能性があります。

複合効果

ここからが本題です。4つの市場で200のドキュメントを管理する企業は、200のドキュメントを管理しているわけではありません。800を管理しているのです。しかし、彼らは200のために人員を配置しています。そこで実際に起こることは

英語版は最新版
ドイツ語版はほぼ最新
フランス語版は遅れています
日本語版は疑問符

聞き覚えがありますか？

ラセピでは200の文書を管理しています。共有コンテンツは自動的に翻訳されます。ローカルコンテンツはローカルチームによって追加されます。すべてのバージョンは英語版と同じ最新版で、地域チームが追加したものはすべてローカル版です。

翻訳コストも抑えられます。英語の段落を1つ更新すると、その段落だけがすべての言語で再翻訳されます。文書全体でもなく、200の文書すべてでもありません。実際に変更された段落だけです。その仕組み](/ja/blog/how-rasepi-translations-work-and-why-they-sound-your-team/)については、翻訳されたコンテンツを自然に聞こえるようにするための用語集やスタイルルールを含めて、詳しく書きました。

簡単な直感チェック

グローバルチームを運営しているなら、自問してみてください：

1.**同じトピックを検索し、言語ごとのコピーを数えます。 2.**ドイツ語、フランス語、日本語の文書の最終編集日を確認してください。どれくらい遅れていますか？ 3.**それとも、上書きされてしまうので、あきらめてしまったのでしょうか？ 4.**英語圏以外のオフィスではオンボーディングにどれくらい時間がかかりますか？

この答えに違和感を覚えたとしても、それはあなただけではありません。ほとんどの企業は、実際にコピーを数えてみるまで、自分たちがどれだけのオーバーヘッドを作り出しているのか気づきません。

ドキュメンテーションは、企業に合わせて拡張すべきものであり、増殖すべきものではありません。あなたが維持するすべてのコピーは、遅れをとったり、新入社員を混乱させたり、他の誰かが読んでいるバージョンと矛盾する可能性のあるコピーです。トピックごとに1つのドキュメントを作成し、共有コンテンツは翻訳し、ローカルコンテンツはあるべき場所に配置することが、グローバル企業におけるドキュメントのあるべき姿です。

あなたのwikiは同じドキュメントのコピーを5つも必要とすべきではありません。1つで十分です。翻訳された共有ステップ、言語ごとのローカルステップ。それだけです。

多言語パブリッシングの実例を見る→

ブロックレベルのローカリゼーションのビジネスケース

2026-03-24T00:00:00Z

国境を越えて事業を展開する企業には、必ずこのパターンがあります。英語のドキュメントはしっかりしています。ドイツ語版は3ヶ月遅れています。日本語版は業者が一度翻訳したきり、誰も手をつけていません。ブラジルのポルトガル語版は、サンパウロが最も急成長しているオフィスであるにもかかわらず、まだ存在していません。

これは誰もが認める問題です。誰も良い解決策を持っていません。これまでは、ローカライゼーションはプロジェクトとして扱われ、予算を組み、実行し、次の大きな見直しがあるまで静かに放置される、一回きりの作業でした。

しかし、このやり方は間違っています。その理由と、私が実際に有効だと考える方法をご紹介します。

翻訳はローカリゼーションではない

用語を整理しましょう。翻訳とは、ある言語で書かれたテキストを、別の言語で同等のテキストにすることです。ローカリゼーションとは、知識を特定の市場で機能させることです。両者は重なりますが、同じものではありません。

翻訳された文書は正しく読まれます。ローカライズされた文書は自然に読まれます。文化的背景、地域の規制、現地のツール、そしてその市場の人々の実際の働き方を考慮します。

この違いが重要なのは、ほとんどのドキュメンテーション・プラットフォームがローカリゼーションを翻訳作業として扱っているからです。英語で書いてボタンを押すと、フランス語で出力されます。完了。というのも

フランスのチームには、英語のドキュメントではカバーできない別のデプロイメントプロセスがあります。
ドイツのコンプライアンス要件により、他にはない承認ステップが追加されるため。
日本のオフィスでは、同じワークフローに別の社内ツールを使っています。
ブラジルのポルトガル語圏の読者は、他では関連性のない現地の税制に関するコンテキストを必要としています。

**英語のドキュメントをそのまま翻訳しても、技術的には正しいのですが、実質的には役に立ちません。

ドキュメントレベルの翻訳の問題点

伝統的なローカリゼーションは文書レベルで行われます。英語のドキュメントがあります。全体をドイツ語に翻訳します。英語版が変更されたら、全体を再翻訳に出します。これには3つの問題があります：

1.コストがかかる

オンボーディングガイドに15のセクションがあり、1つの段落を変更すると、15すべてのセクションを再翻訳することになります。これを8つの言語で掛け合わせると、編集のたびに予算の話になります。

2.時間がかかる

完全な文書を翻訳に出すには時間がかかります。最新の機械翻訳を使用しても、文書全体のレビューサイクルは、変更箇所を1つレビューするよりも大幅に長くなります。他の言語のチームは常に遅れています。

3.独自コンテンツに対応していない

これが最大の問題です。ドイツ語版にDSGVOコンプライアンスに関する追加セクションが必要な場合、どこに追加するのでしょうか？文書レベルの翻訳システムでは、ドイツ語版に追加されたコンテンツは、次に誰かが英語から再翻訳するときに上書きされてしまいます。ドイツ語チームはすぐに学習します：何も追加してはいけません。

ブロックレベルのローカリゼーション：異なるアーキテクチャ

ラセピは文書を翻訳しません。個々の段落、見出し、セクションを翻訳し、それぞれが独自のIDとコンテンツハッシュで独立して追跡されます。

これが実際に何を意味するかは以下の通りです：

英語の一つの段落を編集すると、RasepiはSHA256コンテンツハッシュを比較することで、どのブロックが変更されたかを検出します。その1つのブロックだけが、DeepLを介して翻訳のために送信されます。文書内の他の14ブロックは、以前のままです。翻訳コストは最大94%下がります。

ドイツ語翻訳者がDSGVOセクションを追加する必要がある場合、ドイツ語バージョンに新しいブロックとして追加します。このブロックはドイツ語版のみに存在します。英語のソースには影響しません。英語が変わっても上書きされません。独自のコンテンツとしてフラグが立っているので、意図的なものだと誰もがわかります。

例えば、日本語のテクニカルライティングでは、箇条書きの代わりに番号付きリストが一般的であるため、日本語版では異なる構造が必要になった場合、翻訳者はブロックタイプを変更することができます。システムはこれを「構造適応」として追跡し、将来の更新にわたって保存します。

各言語のバージョンは、シャドーコピーではなく、ファーストクラスのドキュメントになります。

技術的な仕組み

ラセピのすべてのブロックは

UUID**は、すべての編集と翻訳に渡って持続します。
テキストが変更されたときに変更されるコンテンツハッシュ** (SHA256)
A position index そのため、ブロックは正しい順番で並びます。
英語のブロックを削除しても、他の言語のアライメントが崩れないようにするソフト削除フラグ**。

翻訳ブロックが作成されると、ソースブロックのコンテンツハッシュが保存されます。保存するたびに、システムはハッシュを比較します。ハッシュが一致した場合、翻訳は最新になります。一致しない場合、翻訳は古いとマークされ、その特定のブロックにのみ注意が必要です。

これが、94％のコスト削減を可能にしたメカニズムです。ほとんどの編集は1つか2つのセクションを変更します。ドキュメントの残りの部分は、すべての言語にわたって変更されません。

言語ごとの独自コンテンツ

ここが他のプラットフォームと大きく異なる点です。

ラセピでは、各言語のバージョンに以下を含めることができます：

Translated blocks. ソース言語の直接翻訳。
Unique blocks. その言語にしか存在しない、ローカルチームによって追加されたコンテンツ
Structure-adapted blocks. 同じソース・コンテンツで、異なるフォーマットまたはブロック・タイプ

1つの文書が言語間でこのようになる可能性があります：

| ブロック｜英語（ソース）｜ドイツ語｜日本語 |-------|------------------|--------|----------| | 1｜はじめに｜翻訳済み｜翻訳済み｜翻訳済み｜翻訳済み｜翻訳済み｜翻訳済み | 2｜セットアップの手順｜翻訳済み｜構造を適応（番号付きリスト）｜翻訳済み｜翻訳済み｜翻訳済み | 3 | - | DSGVOコンプライアンス（ユニーク） | - | | 4 | 配置｜翻訳済み｜翻訳済み｜翻訳済み｜翻訳済み｜翻訳済み｜翻訳済み｜翻訳済み｜翻訳済み | 5｜ -｜ -｜ローカル・ツーリング・ノート（ユニーク | 6 | トラブルシューティング | 翻訳された | 翻訳された |

すべてのチームが必要なドキュメントを正確に入手できます。妥協なし。回避策なし。画一的な制限もありません。

言語を超えた鮮度追跡

各言語版は、それぞれ独立して鮮度を追跡します。英語のソースは94点（最近レビューされた、すべてのリンクが有効、高い読者数）。フランス語版は71点（2つのブロックが古く、フランス語コンテンツ特有のリンク切れが1つ）。日本語版は88点（すべての翻訳が最新だが、読者数は減少中）。

この言語ごとの鮮度追跡が意味するのは

注意が必要な言語を正確に把握
古くなった翻訳は自動的に表示され、偶然発見されることはありません。
AIツールは、回答を提供する際に言語固有の鮮度を考慮することができます。
ダッシュボードは、ドキュメントごとだけでなく、言語ごとにコンテンツの健全性を表示します。

ビジネスケース

言語を超えて事業を展開する企業は、シンプルな現実に直面しています。

ベルリンのチームが、英語のソースから3か月遅れているドイツ語の翻訳を基に仕事をしている場合、彼らは古い情報に基づいて意思決定をしています。東京オフィスでは、翻訳システムが上書きしてしまうため、共有ドキュメントにローカルのコンテキストを追加することができません。サンパウロのチームがポルトガル語のドキュメントをまったく持っていない場合、オンボーディングに2倍の時間がかかります。

コストは翻訳料だけではありません。それは

非英語圏でのオンボーディング**の遅れ
チームがローカルツールで並行したドキュメントを維持するための重複した労力。
公式Wikiが全員をサポートしない場合に形成される知識のサイロ。
地域特有の要件が把握されない場合の**コンプライアンスリスク
ドキュメンテーションシステム自体への信頼の喪失

ブロック・レベル・ローカリゼーションは、翻訳を安くすることではなく（安くすることはできますが）、すべての言語バージョンを生きた、メンテナンスされた、信頼できるドキュメントにすることで、これらすべてを解決します。

はじめに

もしあなたが今、どのドキュメントプラットフォームでも多言語チームを運営しているのであれば、ここで簡単な直感チェックをしましょう：

1.**最も重要な文書を選んでください。各バージョンは最新ですか？ 2.**あなたの非英語チームに尋ねてください。彼らはそれを使っていますか？ 3.3.**シャドウ・ドキュメンテーションを探しましょう。**公式ドキュメントが役に立たないので、チームはローカルのWikiやNotionページ、Slackのピン留めメッセージを管理していますか？ 4.**また、そのうちのどれだけが、変更されていないコンテンツの再翻訳ですか？

もし答えに違和感があれば、それは貴社だけではありません。ほとんどの企業は、コンプライアンス上の問題、配備の失敗、時代遅れの指示に従ったために 2 週間も費やしてしまった新入社員など、実際に問題が発生するまでギャップに気づきません。

多言語の知識はあればいいというものではありません。国境を越えて事業を展開する企業にとって、多言語知識はチームの連携、意思決定、出荷の基盤です。問題は、ドキュメント作成プラットフォームがそのように扱っているかどうかです。

すべての言語は、ナレッジベースの第一級市民であるべきです。コピーではありません。影でもありません。本物の、メンテナンスされた、信頼できるドキュメントです。

Rasepi はそれを実現します。ブロックレベルの翻訳、言語ごとのユニークなコンテンツ、独立した鮮度追跡、翻訳コストの94％削減。すべて自動です。すべて初日から。

多言語パブリッシングの実例を見る→

コンテンツの鮮度、パート2：有効期限を超えて

2026-03-18T00:00:00Z

*これは、コンテンツ・フレッシュネス・シリーズのパート2です。パート1では、なぜ鮮度が重要なのか、そして実際にどのような意味があるのかを説明しています。この記事では、その続きとして、賞味期限だけでは十分でない理由と、継続的なモニタリングとはどのようなものかについて説明します。

あなたが責任あることをするとしましょう。あなたが責任あることをするとしましょう。作成から6ヶ月、安定した参考資料の場合は12ヶ月かもしれません。日付が来ると、所有者は通知を受け取ります。

これはほとんどの会社がやっていることよりも良いことです。ほとんどの会社は何もしません。ドキュメントがそこに置かれ、ゆっくりと腐敗していき、誰かが指示に従って何かが壊れるまで誰も気づきません。

しかし、ここに不愉快な真実があります：**有効期限は必要ですが、まったく不十分です。**私は、文書が最後のレビューから数日後に危険なほど古くなるのを見たことがありますが、レビューの日付ではそれを捕らえられません。

##有効期限が実際に解決すること

有効期限は説明責任の問題を解決します。それは、次の質問に答えるものです：これがまだ正確であることを、誰が、いつ確認する責任がありますか？

これは本当に価値のあることです。これがないと、ドキュメンテーションは所有権の空白と呼ばれる状態に陥ります。レビュー日を設定することで、特定の日に一人の人間に一人の義務を課すことができます。シンプル。明確。効果的。

実際の有効期限はこんな感じです：

文書が作成され、90日後にレビューが行われます。
有効期限の14日前に所有者に通知
有効期限が切れると、文書に「要レビュー」のフラグが立てられます。
オーナーがレビューし、まだ正確であることを確認し、期限を延長します。
または、更新、再割り当て、アーカイブ化

これは堅実なシステムです。緩慢な腐敗、1年間誰も考えなかったドキュメントをキャッチします。定期的なレビューが行われます。オーナーシップの可視化

**しかし、大陸ほどの死角があります。

失効日が見逃すもの

レビューの日付と日付の間は、文書はブラックボックスに格納されます。あなたはそれを1月15日に見直しました。次の見直しは4月15日です。2月3日には、これらのどれかが起こる可能性があります：

リンクが無言で切れる

参照した外部URLが404を返しました。内部リンクがアーカイブされたドキュメントを指しています。コードリポジトリの名前が変更され、文書内の GitHub リンクがすべて無効になりました。ドキュメントはまだ正常に見えます。有効期限はあと2ヶ月もありません。リンクが切れていることを誰も知りません。

読者数はゼロに

あなたの文書は、かつては毎月40人に読まれていました。その後、プロセスが変わり、誰も必要としなくなりましたが、誰もアーカイブしていません。検索結果で場所を取り、時折、無関係だと知らない新入社員を混乱させます。有効期限は読者には関係ありません。予定通りに所有者にpingが送られます。

翻訳の遅れ

英語のソースは2月10日に更新されました。フランス語、ドイツ語、日本語の翻訳は現在古くなっています。しかし、これらの翻訳版の有効期限は5月までありません。3ヶ月間、英語以外のチームは古くなったコンテンツを読んでいることに気づかないのです。

読者が問題を指摘

ある読者がコメントを残しています：「CLIフラグは非推奨になりました。そのコメントはそのままになっています。有効期限はまだ数週間先です。次にドキュメントを読む人はそのコメントを見ないかもしれません。その次の人は間違いなく見ないでしょう。

**有効期限は予定されたチェックポイントです。これらは予定外の出来事です。この2つの間のギャップが、古くなった文書が最もダメージを与えるところです。

鮮度：継続的モニタリング

フレッシュネス・スコアリングは、有効期限のギャップを埋めるものです。90日に一度、ドキュメントの健全性をチェックする代わりに、フレッシュネスは継続的にドキュメントを追跡します。毎日、バックグラウンドで、誰も何もする必要がありません。

これがラセピの仕組みです：

すべての文書は、複数のシグナルから計算された0から100までのライブ鮮度スコアを取得します：

|--------|----------------|----------------|

| レビュー状況**｜ドキュメントがスケジュール通りにレビューされたかどうか｜基本的なアカウンタビリティチェック | 読者の傾向**｜実際に読んでいる人がいるかどうか｜読者が少ないということは、そのドキュメントが無関係である可能性を示唆しています。 | 編集の新しさ**｜ドキュメントが最後に更新されたのはいつなのか、関連するコンテンツとの比較｜周囲の知識ベースとの相対的なずれを検知｜翻訳アライメント｜ドキュメントが実際に翻訳されているのかどうか｜翻訳アライメント | 翻訳アライメント｜すべての言語バージョンが最新かどうか｜翻訳が古いということは、他の市場のチームが古い情報を元に作業していることを意味します。 | 読者フラグ**｜読者からの問題報告の有無｜クラウドソーシングによる陳腐化検知 | 相互参照**｜この文書がリンクしている文書自体が古くなっていないか？

各シグナルは全体のスコアに貢献します。ある文書は、レビュー日が数週間先であっても、今日リンク切れで鮮度ポイントを失う可能性があります。それが重要なのです。

この2つの連動性

有効期限と鮮度は競合するアプローチではありません。補完し合うものなのです：

賞味期限はガバナンス層です。有効期限**はガバナンスレイヤーです。誰かがスケジュール通りにこのドキュメントを見て、まだ正確であることを確認しなければなりません。内容*がまだ正しいかどうか、アドバイスがまだ健全かどうか、記述されているプロセスがまだ現実を反映しているかどうか。

フレッシュネス・スコアリングはモニタリング・レイヤーです。リンク切れ、翻訳ドリフト、放置された文書、世界が動いて文書が動かないときに起こる文脈の崩壊など、レビューの日付と日付の間にあるすべてのものをキャッチします。

これらを組み合わせることで、以下のようなシステムが構築されます：

1.すべての文書は、定期的なスケジュール（有効期限）で人間によってレビューされます。 2.レビューの合間に、自動化されたシグナルが問題を随時キャッチ（鮮度） 3.両システムは、誰もが見ることのできる単一の信頼スコアに反映されます。 4.このスコアは、検索における文書のランク付けや、AIツールがその文書をソースとして使用するかどうかに影響します。

スコアリングインパクト

ここからが実用的です。ラズパイでは、ドキュメントの鮮度スコアがその可視性に直接影響します：

スコア 80-100:** 完全な可視性。検索結果に普通に表示されます。AIの回答ソースとして適格。フラグなし。
スコア50-79:** 視認性低下。陳腐化インジケータ付きで検索結果に表示されます。AIツールはソースとしての優先順位を下げる可能性があります。所有者に通知されます。
スコア50以下:**フラグ付き。検索結果で大幅に押し下げられます。AI回答から完全に除外。オーナーに緊急通知。

これはフィードバックのループを作ります。ドキュメントのスコアが下がると、オーナーはそれを修正するように促されます。リンク切れ、翻訳の古さ、読者数の減少、これらは6週間後ではなく、今すぐ注意を払うべき現実のシグナルなのです。

実例

あるシナリオを見てみましょう：

**月1日：**あなたの「インシデント対応プレイブック」は92点です。それは2週間前にレビューされ、すべてのリンクは有効で、読者数は多く、4つの言語バージョンはすべて最新です。

**3月8日：**誰かがエンジニアリング・ステータスのページを再構築しました。プレイブック内の3つのURLがリダイレクトされるようになりました。鮮度スコアは78に低下。オーナーは通知を受け取ります：「3つのリンク切れを検出しました。

**3月10日：**オーナーはリンクを修正。スコアは89に回復。

月15日： 英語版は新しいエスカレーションパスで更新されています。フランス語とドイツ語の翻訳が古くなりました（コンテンツハッシュの不一致）。スコアは74に低下。

月17日： 翻訳が更新されました。スコアは91に戻りました。

**3月20日：**読者データによると、日本語版は30日間アクセスなし。スコアは86に低下。微妙なシグナル。

**4月1日：**レビュー予定日。読者数シグナルがまだ存在するため、スコアは86のまま。

チームは問題を発見するために審査日を待ったことはありません。鮮度システムは数日以内に問題点にフラグを立てました。審査日はガバナンスのチェックポイント。どちらのレイヤーも役割を果たしています。

なぜ「レビュー日を設定するだけ」ではもう十分ではないのか

5年前なら、有効期限だけで十分だったかもしれません。ドキュメントは人に読まれ、人は判断することができます。文書が少しおかしいと思えば、周囲に問い合わせるでしょう。

今日、ドキュメンテーションはインフラです。AIツール、オンボーディング・オートメーション、コンプライアンス・システム、文脈のない結果を提供する検索エンジン。これらのシステムは判断を下しません。コンテンツをそのまま利用し、大規模に再配布するのです。

リンク切れや翻訳が古く、レビュー日まで3週間もあるようなドキュメントは、特にAIアシスタントが自信を持ってそのドキュメントに基づいた回答を提供する場合、その3週間で大きなダメージを与える可能性があります。

**有効期限は、ドキュメント・ガバナンスにとって最低限実行可能なアプローチです。鮮度スコアリングは、ドキュメントが自分で考えることができないシステムによって消費される場合に必要なものです。

はじめに

すでに文書に有効期限を設定している場合（ほとんどのチームは有効期限を設定していません）、鮮度を高める方法を説明します：

1.**リンクの追跡を開始します。その数はおそらくあなたを驚かせるでしょう。 2.**多言語の文書がある場合、ソースと翻訳の最終編集日を比較してください。1ヶ月以上遅れているものはいくつありますか？ 3.**トラフィックがゼロの文書はどれですか？それらはまだ必要ですか、それともアーカイブすべきですか？ 4.**社内にAIアシスタントがいるのであれば、どのような文書からソーシングしているか聞いてみましょう。そして、それらの文書の鮮度をチェックしましょう。

技術的に有効期限が切れていない文書には、有効期限では決して捉えられない問題がたくさんあることに気づくでしょう。

有効期限は、誰かがその文書を最近チェックしたかどうかを教えてくれます。鮮度は、その文書が実際に今元気かどうかを教えてくれます。一つはカレンダーのイベント。もう一つは生きているシグナルです。

両方が必要です。しかし、有効期限だけでは、チェックポイントとチェックポイントの間を盲目的に飛行しているようなものです。

文書はレビュー日に古くなるのではありません。古くなるのは、何かが変わって誰も気づかない瞬間です。鮮度スコアリングはそれに気づきます。

ラセピは、強制的な有効期限と継続的な鮮度監視を組み合わせています。全ての文書はリアルタイムで信頼スコアを獲得し、または失います。待ち時間も、盲点も、レビュー時の驚きもありません。

鮮度スコアの仕組みはこちら→

これは2部構成の第2部です。まだお読みでない方は、Part 1: The Metric Your Team Isn't Tracking. からお読みください。

コンテンツの鮮度、パート1：あなたのチームが追跡していない指標

2026-03-16T00:00:00Z

どのエンジニアリングチームでも経験する瞬間があります。誰かが社内のWikiでドキュメントを見つけ、その指示に従ったところ、何かが壊れてしまったのです。彼らはチャンネルにメッセージを送ります：これはまだ正確ですか？これを書いた人は8ヶ月前に退職しました。ドキュメントによると、最終編集は2024年。

これが鮮度の問題です。さらに悪化しています。

古い契約は崩壊しつつあります

長い間、ドキュメントには暗黙の契約がありました：誰かがそれを書き、誰もがそれを信頼し、時々誰かがそれを更新する。そうかもしれません。その契約は、ドキュメントが判断力のある人たちによってのみ消費されていた時代には、かろうじて機能していました。セットアップ・ガイドが少しおかしいと思えば、シニア・エンジニアがその場で修正することもありました。

しかし、そのような世界は終わりました。今日、ドキュメントを読むのは人間だけではありません。AIツール、社内チャットボット、オンボーディング・オートメーション、そしてすべての言葉を同等の真実として扱う検索システムによって消費されるのです。AIアシスタントはドキュメントに目を細めて「うーん、これはちょっと古そうだな」とは考えません。

**古い文書とAIは、自信を持って間違った答えを出すのと同じです。

新鮮さが実際に意味するもの

鮮度とは、単に「これが最後に編集されたのはいつか」ということではありません。昨日編集されたドキュメントでも、まだ非推奨のAPIを参照しているかもしれません。真の新鮮さとは、複合的なシグナルです：

レビュー状況。
Link health. ドキュメント内のURLはまだ解決されていますか？
読者数.** これを実際に使っている人はいますか、それとも放棄されましたか？
Contextual drift. この文書が同じままで、関連文書が変わりましたか？
これが5つの言語で存在する場合、それらのすべてが最新ですか？
Community signals. 読者がこれを古いとフラグを立てましたか？

これらはそれぞれ異なることを教えてくれます。これらを総合して、信頼スコアが算出されます。信頼スコアは、今現在、コンテンツにどれだけの信頼を置くべきかを表す1つの数値です。

なぜ今これが重要なのか、具体的には

3つのことが重なり、鮮度が急務となっています：

1.AIが知識ベースを消費

社内にRAGシステムを導入している場合でも、IDEでCopilotを使用している場合でも、ドキュメントからの質問にAIアシスタントが答えている場合でも、ソースの質がアウトプットの質を直接決定します。ゴミを入れ、ゴミを出すことは、かつてないほど文字通りのことです。

開発者がAIアシスタントに "ステージングへのデプロイはどうすればいいですか？"と質問し、AIアシスタントが2年前のランブックを使って回答し、その後移行したインフラを参照した場合、その代償は間違った回答だけではありません。システム全体に対する信頼を失ったのです。

2.チームはかつてないほど分散化

ベルリンのチーム、サンパウロのチーム、東京のチーム。全員が同じドキュメントを、しばしば異なる言語で読んでいます。英語のソースが古くなると、その上に構築されたすべての翻訳も古くなりますが、翻訳は別々にメンテナンスされるため、誰も気づきません。

3.コンプライアンスと監査へのプレッシャーの増大

規制業界は、「この文書が参照された時点で最新であったことを証明できますか？この文書が参照された時点で最新のものであったことを証明できますか？

新鮮さ第一のアプローチとはどのようなものか

核となる考え方はシンプルです：**すべての文書は、信頼される権利を継続的に獲得しなければなりません。

ということです：

1.**すべての文書には、作成時に有効期限が設定されます。例外はありません。期限が来ると所有者に通知され、誰かが明示的に再承認するまで文書にフラグが立てられます。

2.**バックグラウンドで、システムはリンク切れ、読者動向、文脈の変化を継続的にチェックします。これらのシグナルは、誰も何もしなくても更新されるライブスコアに反映されます。

3.**これが重要なメカニズムです。スコアの高い文書は検索結果の上位に表示され、AIの回答ソースとして使用されます。スコアの低いドキュメントはランキングが下がります。閾値を下回ると、AI回答から完全に除外されます。

4.**透明性.**文書がなぜそのように採点されたかを誰もが見ることができます。リンク切れ、レビュー期限切れ、読者数の少なさなど、誰も読まないバックエンドレポートに隠されたシグナルではなく、目に見えるシグナルです。

何もしないことの代償

鮮度を追跡しないとどうなるか：

新入社員は時代遅れのオンボーディング・ドキュメントに従い、最初の1週間を戸惑いながら過ごすことになります。
AIツールは間違った答えを出し、誰もその理由を理解できません。
コンプライアンス文書が無言のうちに古くなり、監査リスクが生じます。
翻訳が同期せず、異なる地域のチームが異なる現実のバージョンで作業することになります。
エンジニアがWikiを完全に信用しなくなり、Slackメッセージに戻り、ナレッジサイロが形成されます。

古くなったドキュメントの複合コストは莫大ですが、何かが壊れるまでは見えません。

現実的な出発点

一度にすべてをオーバーホールする必要はありません。これらから始めましょう：

1.**最もよく読まれている文書トップ20を監査してください。リンクはまだ有効ですか？内容は正確ですか？

2.**たとえ他に何もしなくても、すべての文書に「レビュー期限」を設定することで、説明責任が生まれます。

3.**社内にAIアシスタントがいるのであれば、それがどのような文書から取得しているかを見てください。それらの文書は最新のものですか？

4.**検索結果やサイドバーの文書タイトルの横にスコアを表示しましょう。見えるようにすることで、維持するプレッシャーが生まれます。

ドキュメントの鮮度は機能ではありません。組織の知識に対する考え方の根本的な転換です。AIツールが大規模にドキュメントを消費し、再配布する世界では、問題は鮮度にこだわる余裕があるかどうかではありません。そうしない余裕があるかどうかです。

すべての文書は、それがまだ信頼に値するものであることを証明しなければなりません。一度だけではありません。継続的に。

ラズパイではそれを目指しています。新鮮さを後回しにしないプラットフォーム。それは、他の全ての土台となるものです。レビューの実施、ライブヘルススコアリング、鮮度に重点を置いた検索、信頼できるソースのみを使用するAI回答。

仕組みを見る→

*これは2部構成の前編です。Part 2: Beyond Expiry Dates](/ja/blog/expiry-dates-are-just-not-enough/)では、継続的な鮮度モニタリングが、レビューの日付が空けたギャップをどのように埋めるかを探ります。

古くなったドキュメントを無視するように AI に教えましょう。

2026-03-12T00:00:00Z

社内のナレッジベースの上にAIアシスタントを配置すると、次のようになります：

新人エンジニアが尋ねます："ステージング環境はどのように設定すればいいですか？"

AIはドキュメントを検索し、3つの関連ドキュメントを見つけ、答えを合成し、自信を持って提示します。エンジニアはその指示に従います。最初の2つのステップはうまくいきます。ステップ3では、半年前に非推奨となったCLIツールを参照します。ステップ4では、誰も文書化していないマイグレーション中に置き換えられたインフラセットアップについて説明します。

エンジニアは行き詰まりました。チームチャンネルにメッセージを送ります。誰かがこう言います。AIはそれを知りませんでした。AIはそんなことは知りません。AIはただ、見つけたものすべてを取ってきて、それを真実として提示しただけなのです。

**これは、すべてのRAGシステム、すべてのAI検索ツール、そしてあなたが社内のドキュメントで使ったことのあるすべてのLLMを搭載したアシスタントのデフォルトの動作です。彼らはすべてを取得します。彼らは区別しません。彼らは古いものから新しいものを見分けることができません。

そして、AIツールに対する信頼は、ツールがそれを構築するよりも早く破壊されています。

なぜAIアシスタントは品質を見抜けないのか

大規模な言語モデルと検索支援生成（RAG）システムは、クエリに意味的に関連するテキストを見つけ、そのテキストを使って答えを生成します。通常、関連性のマッチングは優れています。ベクトル検索と埋め込みは、質問に関連するコンテンツを見つけることに純粋に優れています。

しかし、関連性と信頼性は同じではありません。

Kubernetesのデプロイプロセスについて2023年に書かれたドキュメントは、"本番環境へのデプロイ方法は？"という質問と非常に関連性があります。また、2024年に別のプラットフォームに移行した場合は、完全に間違っています。AIは関連するテキストを見ます。リンク切れで読者がゼロの18ヶ月前のドキュメントを見ることはありません。

ほとんどのAIシステムはランキングシグナルを1つしか持っていません：**クエリとの意味的類似性。それだけです：

この文書が最後に見直されたのはいつですか？
リンクはまだ有効か？
この文書を実際に読んでいる人はいますか？
コンテンツが古いとして読者からフラグが立てられていないか？
これは草案ですか、アーカイブされたページですか、それとも最新の文書ですか？
この文書が複数の言語で存在する場合、翻訳は最新ですか？

これらのシグナルがなければ、AIは余計なステップを踏んでキーワードマッチングを行っていることになります。確かに印象的なキーワードマッチングですが、基本的に、AIが返す答えが信頼できるコンテンツに基づいているかどうかをあなたに伝えることはできません。

信頼性の問題

AIツールが不確かな答えを適切な注意書きとともに提示してくれるのであれば、これほど危険なことはありません。しかし、そうではありません。LLMはそうはいきません。LLMは、原文が最新のものであろうと古代のものであろうと、流暢で自信に満ちた文章を生成します。

ウィキの記事を読む人間は、その記事が古く見えることに気づくかもしれません。ページレイアウトが古い。スクリーンショットはもう存在しないUIを示しています。一番下に "これは時代遅れです "というコメントがあります。人間は判断を下すことができます。

AIにはできません。AIはテキストを読み、それを他のテキストと同等に処理し、権威的に聞こえる答えを生成します。ユーザー、特に現在のプロセスを知らない新入社員は、それを疑う理由がありません。

**AIが自信ありげに聞こえれば聞こえるほど、陳腐なソースが与えるダメージは大きくなります。

AIが実際に必要とするもの

AIアシスタントがあなたの知識ベースから信頼できる答えを出すためには、テキストや埋め込み以上のものが必要です。どの文書がソースとして使用する価値があるかを示すメタデータが必要です。具体的には

1.鮮度スコア

ドキュメントが今どのくらい健全かを表す数値信号。最終編集日ではありません。真の鮮度スコアは、レビュー状況、リンクの健全性、読者数、翻訳アライメント、文脈ドリフトを1つの数値にまとめたものです。

ある文書がしきい値（例えば100点満点中70点）を上回ると、AIの回答ソースとして使用する資格があります。しきい値を下回ると除外されます。例外はありません。

このたった一つのメカニズムが、AIの誤答の中で最も危険なクラスである、古くなったソースに基づく確信犯的な誤答を排除します。

2.期限切れステータス

この文書は現在レビュー期限内ですか、それとも再承認されずに期限切れですか？期限切れの文書は、その内容がクエリにどれだけ関連しているかにかかわらず、優先順位を大きく下げるか、完全に除外してください。

ラズパイでは、期限切れの文書にはフラグが立てられ、鮮度スコアは自動的に下がります。ナレッジベースを照会するAIシステムは、このステータスを確認し、それに基づいて行動することができます。

3.分類ラベル

すべての文書が同じ目的を果たすわけではありません。草稿はソースとして使用すべきではありません。アーカイブされた文書はAIの回答に表示されるべきではありません。社内専用文書は、社外向けツールからのクエリに表示されるべきではありません。

分類ラベルは、AIにどのような文書を見ているかというコンテキストを与えます：

Published.**最新、承認済み、安全に使用可能
Draft.**作業中、引用されるべきではありません。
有効期限切れ、再承認待ち。
Archived. もはやアクティブではありません、参考のためにのみ保管されています。
Internal / External. 可視範囲を制御します。

AIアシスタントがクエリを処理する際、コンテンツの関連性を見る前に分類によってフィルタリングすることができます。クエリに完全に一致するドラフト文書は、決して回答として提供されるべきではありません。

4.言語レベルのシグナル

ナレッジベースが多言語である場合、AIは引き出されているバージョンが最新かどうかを知る必要があります。英語のソースから3ヶ月遅れているフランス語の翻訳は、フランス語では技術的に適切ですが、情報が古い可能性があります。

ラセピは言語レベルで鮮度を追跡します。各翻訳は、その翻訳が最後に更新されてからソースブロックが変更されたかどうかに基づいて、独自のスコアを持ちます。フランス語のナレッジベースを照会するAIは、フランス語版の文書が古いと判断し、次のいずれかを実行できます：

英語ソース（最新）にフォールバックします。
フランス語版が古くなっている可能性があるという注意書きを含めます。
文書を完全に除外

5.読者シグナル

複数の読者がそのドキュメントに古いとフラグを立てた場合、そのシグナルはAIの回答におけるそのドキュメントのウェイトを下げるはずです。クラウドソーシングの品質シグナルはノイズが多いですが、特に他の鮮度メトリクスと組み合わせた場合は価値があります。

実際にどのように機能するか

AIアシスタントがRasepiの知識ベースに問い合わせをしたときに何が起こるかを見てみましょう：

クエリ: "午前2時のP1インシデントを処理するプロセスは何ですか？"

Step 1: Retrieval with filtering. システムは、意味的に関連する文書を検索します。ランキングの前に、フィルタリングを行います：

鮮度スコアがしきい値以下の文書
再承認されていない期限切れ文書
下書きやアーカイブされたコンテンツ
言語バージョンが古い文書（クエリが主要言語以外の場合）

**残りの文書の中で、鮮度スコアが高いものが上位にランクされます。たとえ72点の文書の方が意味的類似度が多少高くても、94点の文書は72点の文書を上回ります。

**AIは、フィルタリングされ、鮮度ランク付けされたソースから回答を生成します。すべてのソースは、その鮮度スコアが見えるように引用されます。

ステップ 4: 新鮮さの警告. 最も利用可能なソースが鮮度スコアの境界線上にある場合、AI は注意書きを含めます: _"注意: この回答の主なソースは、60 日前に最終レビューされました。チームに確認してください。

これをデフォルトの動作と比較してみましょう：関連するテキストを見つけ、自信のある答えを生成し、最善を望みます。

これをしないとどうなるか

フィルタリングされていない知識ベースで動作するAIシステムの結果は予測可能で高価です：

**新入社員の混乱.**社内ドキュメントに対する最も一般的なAIのユースケースは、オンボーディングです。新入社員は、定義上、何が最新で何が古いかわかりません。彼らはAIを信頼します。AIはすべてを信頼します。古くなったドキュメントは、自信を持って提供されます。

**AIアシスタントが古い文書を使って規制プロセスに関するガイダンスを提供した場合、そのアドバイスは間違っているだけでなく、コンプライアンス違反かもしれません。「AIに言われたから」は監査では通用しません。

**AIが間違った回答をするたびに、ユーザーの信頼は少しずつ低下していきます。3、4回ひどい経験をすると、ユーザーはAIを使わなくなります。AIツールへの投資が価値をもたらさないのは、基礎となるコンテンツが信頼に足るものではなかったからです。

**シャドウ・ナレッジ.**公式の知識ベース（とその上に構築されたAI）に対する信頼を失うと、人々は自分自身で知識を作り出します：Slackメッセージ、個人的なメモ、会議で共有される部族的知識。Slackメッセージ、個人的なメモ、会議で共有される部族的な知識などです。ウィキが防ぐはずだった断片化は、異なるだけでとにかく起こります。

修正はモデルではなくソースで

より良いプロンプト、より洗練されたRAGパイプライン、テキストだけからどうにかして陳腐化を検出できる微調整されたモデル。これは間違ったアプローチです。

解決策はソースにあります。ドキュメントが現在の状態に関する豊富で正確なメタデータ（鮮度スコア、有効期限切れステータス、分類、言語アライメント、読者シグナル）を持っていれば、どんなAIシステムもそのメタデータを使ってより良い判断を下すことができます。より賢いモデルが必要なのではありません。より賢い文書が必要なのです。

これがラズパイが提供するものです：

すべての文書は、リンクの健全性、読者数、レビュー状況などに基づいて継続的に更新されるライブ鮮度スコア**を持ちます。
全ての文書には有効期限**があり、文書が到着するとレビューが開始されます。
すべての文書には分類**（公開、ドラフト、レビュー中、アーカイブ）があります。
すべての言語バージョンには、独自の鮮度シグナルがあるため、古くなった翻訳は個別に検出されます。
読者フラグと相互参照追跡は、追加の品質シグナルを追加します。

AIシステムがラセピのナレッジベースに問い合わせると、これらのメタデータがすべて利用できます。AIは文書が信頼できるかどうかを推測する必要はありません。文書が教えてくれます。

実用的な出発点

今日、知識ベースでAIアシスタントを稼動させれば、30分で問題の評価を始めることができます：

1.**AIアシスタントにあなたが答えを知っている10の質問をします。おそらく、10個のうち少なくとも2-3個は、古いコンテンツに基づいていることがわかります。

2.**AIが出したそれぞれの答えについて、ソース文書を見てください。最後に見直されたのはいつですか？リンクは有効ですか？自分で読んでも信用できますか？

3.**最も古く、最も放置されている文書で、検索結果にまだ表示されているものを見つけてください。AIにそれを表示するような質問をしてください。AIはそれを使いますか？ほぼ間違いなく使います。

4.**あなたのAIアシスタントは1日に何件のクエリを処理しますか？もし回答の20～30%が古くなったコンテンツに基づいているとしたら、無駄な時間、間違った判断、信頼の喪失という点で、どれだけのコストがかかるでしょうか？

AIアシスタントが優れているのは、その上に構築されたコンテンツだけです。現在、AIアシスタントのほとんどは、ナレッジベース内のすべてのドキュメントを等しく有効なものとして扱っています。昨日レビューされた文書も、2年間誰も触っていない文書も、すべてを取得し、同じ自信をもって提示します。

それはモデルの問題ではありません。データ品質の問題なのです。解決策は簡単です。AIツールに何を信頼すべきかを伝えるメタデータを文書に与えることです。

AIアシスタントは、18ヶ月間誰もレビューしていない文書から得た答えに自信を持つべきではありません。適切なシグナルがあれば、そんなことはありません。

ラセピは、すべての文書に、鮮度、有効期限、分類、言語アライメントといった独自の信頼スコアを持たせます。AIツールはナレッジベースにクエリーを行い、コンテンツだけでなくコンテキストも取得します。信頼できる情報源は浮上します。古いものは出てきません。これが、AIを活用したドキュメントのあるべき姿です。

ラセピとAIツールの連携はこちら→

ドキュメントを読むより、話す方が気分がいい

2026-03-10T00:00:00Z

何か複雑なことをするときに、「最後まで話しましょう」と言われるのには理由があります。

新しいアイデアを理解しようとするとき、問題を解決しようとするとき、プレッシャーの中でプロセスを思い出そうとするとき、会話は読むよりも簡単に感じることがよくあります。読書が悪いからではありません。読書は人類が開発した最も強力なツールのひとつです。しかし、読書は、もっと古いもの、つまりスピーチの上に重ねた学習スキルなのです。

私たちは読書家である前に、話し手なのです。

このことは、人々が思っている以上に重要なことです。特に、世界の知識の多くが、文書、Wiki、PDF、そしてどうしても必要なとき以外は誰も開きたがらない長い社内ページの中に存在している現在ではなおさらです。

読書は学習。会話はネイティブ。

人類は何かを書き記す前に、とても長い間会話をしていました。子供は話し言葉を理解することを自然に学びます。読むことは、明確な指導と反復練習、そして何年もの練習が必要です。

識字能力の高い大人でさえ、読むことは聞くことや話すことに比べてより慎重な行為です。視覚的な集中力、継続的な注意力、ワーキングメモリ、ページ上の構造の解釈が要求されます。記号を解読し、文章を解析し、文脈を構築し、何が重要かを判断するのです。

会話はこれとは異なります。情報が話し言葉で、対話形式で伝えられると、脳は異なる経験をします：

視覚的に圧倒されるのではなく、順を追って理解できます。
即座のフィードバックと明確化
大量のテキストをスキャンしたり、フィルターにかけたりする手間が省けます。
実生活で人々がどのように助けを求めているかを反映しています。

最後のポイントは非常に重要です。不確実性の下では、ほとんどの人は本能的に1,500文字を読みたくありません。次に何をすればいいのか？

話すことは認知的摩擦を減らす

文書は静的です。文書にはすべてが一度に書かれています。

それは便利そうに聞こえますし、しばしばそうです。しかし、それは摩擦も生み出します。見出し、吹き出し、リンク、注釈、例、エッジケースでページがいっぱいになると、読者は何を無視すべきかを決めなければならなくなります。これは認知的に高くつきます。

情報システムと話をするときは、たいてい逆の経験をします。

質問は一つ。すると1つの答えが返ってきます。そして次の質問をします。

この対話パターンは、いくつかの重要な点で、精神的なオーバーヘッドを減らします：

1.問題空間を狭める

完全な文書は全体像を提示します。会話は次の有用なステップを提示します。

新しいエンジニアを採用するにはどうすればいいですか？必要なのはオリエンテーションです。会話によって、彼らは小さなことから始め、必要なときだけ拡大することができます。

2.ワーキングメモリーの保存

読書では、頭の中で複数の事柄を整理しながら、関連箇所を探す必要があります。話し言葉や会話によるインタラクションは、その労力を外部に排出します。システムがあなたのためにフィルタリングの多くを行います。

3.社会的に親しみやすい

人間は前後のやりとりに深く適応しています。私たちは尋ねます。誰かが答えます。私たちは改良します。誰かが明確にします。このループは、最も古い学習方法のひとつです。

その "誰か "がシステムであっても、その構造は自然なものです。

読書は受動的なものではありません。それこそがポイントです。

話すことが簡単に感じられる理由のひとつは、読書は人々が思い込んでいるほど楽ではないからです。熟練した読書家はそれを楽そうに見せますが、そのプロセスは非常に能動的です。

上手に読むためには

構造を見極める
重要性の推測
あいまいさを解消
文脈を記憶
あるセクションと別のセクションをつなぐ
読み飛ばすタイミングとスピードを落とすタイミングを判断

これが本当の認知の仕事です。

多くの場面で、その作業は価値があります。深読みはニュアンスや正確さ、長文理解に役立ちます。しかし、他の状況、特に疲れているとき、ストレスが溜まっているとき、過負荷になっているとき、あるいはただ立ち往生しているときには、話す方が精神的に軽いことが多いのです。

これは特に職場で言えることで、通常、人々は理想的な状態で文書作成に取り組んでいるわけではありません。彼らは

タスクの途中
中断
コンテキストの切り替え
何かを素早く解決しようとしているとき
すでに少しイライラしていることが多い

そのような状態では、情報への「会話型アクセス」は、ページファーストのアクセスよりも劇的に良く感じられます。

話すことで変わる情報との関係

ここには感情的な側面もあります。

文書は形式的でよそよそしく感じられます。文書が暗示するのはそれは参考資料としては有用ですが、ためらいを生むこともあります。

会話は寛容に感じられます。曖昧でも構いません。下手なことを聞いてもいいのです。戸惑いを認めることもできます。何を探しているのかよくわからないのですが、アクセス要求に関することが知りたいのです。

なぜなら、人々がしばしば文書を避けるのは、情報が嫌いだからではなく、その情報の正しい部分を見つけるための労力や不確実性が嫌いだからだからです。

話すことはその障壁を減らします。

なぜ今これが重要なのか

長い間、文書は読むしかありませんでした。検索はページを見つけるのに役立ちましたが、インタラクションモデルは変わりませんでした。ページを開き、スキャンし、必要なものを抽出しなければなりませんでした。

それが変わりつつあります。

インターフェイスがより会話的になるにつれ、人々は情報が単に存在するのではなく、反応することをますます期待するようになっています。平易な言葉で必要なことを尋ね、その瞬間に合ったものを受け取ることを望んでいるのです。

だからといって、読書が時代遅れになるわけではありません。役割が変わるのです。

読書は深い層になります。会話はアクセス層になります。

最高のシステムはその両方をサポートします：

オリエンテーションやスピードが必要なときは会話
深さ、検証、または完全な文脈が必要な場合は、読み取り

単純化しすぎるリスク

重要な注意事項が1つあります。情報に対して話すことは、その答えが信頼できるものである場合にのみ気分が良くなります。

会話型インターフェイスが部分的、誤解を招く、または自信過剰な答えを与える場合、ユーザーがソースを直接調べる能力を奪うため、経験は読むことよりも悪くなります。

つまり、未来は「すべての文書を音声に置き換える」ことではありません。未来とは、文書がもたらす知識の深さと正確さを失うことなく、より人間的な方法で文書にアクセスできるようにすることなのです。

そのバランスが重要なのです。会話はより簡単ですが、文書には組織が必要とする耐久性のある構造、詳細、説明責任が残っています。

知識への、より人間的なインターフェース

人は本来、ページ単位で考えるものではありません。質問、物語、断片、対話で考えるのです。

私たちは問いかけます：

これはどういう意味ですか？
まず何をすればいいの？
大事なことは何ですか？
もっと違う説明ができますか？
何が変わったの？

これらは会話の動きであって、読みの動きではありません。

ですから、情報を読むよりも話す方が精神的に楽だと感じる場合、それは知的怠惰の兆候ではありません。たいていの場合、脳が不確実性にアプローチする方法とインターフェイスがマッチしている証拠なのです。

読書が不可欠であることに変わりはありません。しかし、知識への入り口としては、会話の方が、私たちが本来持っているものに近いため、気分がよくなることが多いのです。

私たちはまず読者ではありません。私たちはまず話す人なのです。最も直感的な知識システムは、そのことを覚えています。

別の時代に構築されたドキュメントプラットフォーム

2026-03-08T00:00:00Z

Confluence と Notion は悪い製品ではありません。それは最初にはっきりと言う必要があります。

彼らが成功したのにはそれなりの理由があります。Confluence が多くの企業で社内ドキュメントのデフォルトのホームとなったのは、チームにナレッジを書き、整理し、共有するための中心的な場所を提供したからです。Notionは、柔軟性、よりクリーンなライティングエクスペリエンス、よりモダンな感じのプロダクトサーフェスで人々を魅了しました。

どちらのプラットフォームも、構築された時代の現実的な問題を解決していました。

今問題になっているのは、彼らを取り巻く世界が、彼らの基盤よりも速く変化していることです。

私たちはもはや、ドキュメントをただ書き、保存し、検索すればよいという世界にはいません。ドキュメントがますます期待される世界なのです：

機械可読性
鮮度管理
AIによる検索の安全性
自動化に十分な構造化
言語や読者層を超えた動的性
利用可能なだけでなく、継続的に信頼できる

それは別のハードルです。

AI以前の知識モデルのために作られました

従来のドキュメンテーション・プラットフォームは、ページが存在し、検索可能であれば、問題はほぼ解決するという単純な仮定に基づいて設計されていました。

ページが存在し、検索可能であれば、問題はほとんど解決されます。主なユーザーがウィキを開き、ページをざっと読み、判断を下す人間であったときは、それで十分でした。そのモデルでは、プラットフォームの仕事はオーサリングとナビゲーションを簡単にすることでした。

AIは仕事の内容を変えます。

いまやプラットフォームは、人間のために知識を蓄えるだけではありません。自動的に検索し、ランク付けし、要約し、質問に回答するシステムのためのソースを生成しているのです。

そのため、旧来のアーキテクチャでは優先されなかった新しい要件が導入されます：

今、どのコンテンツが信頼できるのか？
どのコンテンツが現在信頼できるのか？
最近変更されたセクションは？
どの言語バージョンが最新か？
下書き、アーカイブ、地域固有、信頼性の低いコンテンツはどれか？
AIの回答から完全に除外すべき文書はどれか？

このような質問を中心に構築されていないプラットフォームは、後付けしなければなりません。これは、最初からこれらの質問のために設計するよりも常に困難です。

レガシーの強さがレガシーの足かせに

確立された製品には、流通、エコシステム、ブランド、顧客とのなじみ、統合、出荷方法を知っているチームといった強みがあります。しかし、同じ強みは構造的な変化を遅らせる可能性があります。

なぜか？なぜなら、成熟したプラットフォームにはコミットメントがあるからです。

成熟したプラットフォームには

長年の製品決定の蓄積
既存のワークフローを持つ膨大なインストールベース
後方互換性への期待
古い動作に依存するプラグインや拡張機能
昨日のユースケースに最適化されたデータモデル

Confluence や Notion のようなプラットフォームが純粋に新しい機能を追加したい場合、多くの場合、その機能を既存のシステムを通してではなく、既存のシステムにフィットさせる必要があります。

これこそが既存システムの課題です。

AI機能を追加することは、AIネイティブになることと同じではありません。

多くの既存プラットフォームは現在、AIを上乗せしています。要約。ライティング支援。検索の改善。Q&A インターフェース。Confluence には Atlassian Intelligence が、Notion には Notion AI が、GitBook には AI-powered search が追加されました。これらは便利な機能です。良いものもあります。

しかし、これには意味のある違いがあります：

ドキュメント製品にAI機能を追加すること
コア・アーキテクチャが初日からAIの利用を前提としたドキュメンテーション製品の構築

最初のアプローチは、多くの場合、縁の下の力持ち的な機能につながります。2つ目は、基盤を変えることです。

AIネイティブのナレッジ・プラットフォームは、最初から異なる設計上の疑問を投げかけます：

システムが安全に推論できるように、ドキュメントはどのように構造化されるべきか？
信頼はどのように表現されるべきか？
どのようなメタデータがオプションではなく、ファーストクラスでなければならないのか？
古くなったコンテンツはどのように可視性を低下させるべきか？
基礎となるソースが弱い場合、どのように回答を制限すべきか？

これらはアーキテクチャの問題であり、機能の問題ではありません。

新鮮なプラットフォームは一時的に有利

これは、少なくともしばらくの間は、新しいプラットフォームが勝てる点です。

新しいプラットフォームには、昨日の習慣の代わりに今日の制約を中心に設計する自由があります。ドキュメントとは何か、Wikiはどのように振る舞うべきかについて、10年来の前提を維持する必要はありません。早期に異なる選択をすることができます：

新鮮さを第一級の概念として扱うこと
人間とマシンの両方にソースの信頼を可視化すること
コンテンツの状態に関するより豊富なメタデータの保存
多言語ワークフローをボルトオンではなく、コアモデルに組み込むこと。
検索とAIによる検索は、関連性だけでなく、信頼性によってランク付けされるべきであると決定。

自由は重要。

テクノロジーの世界では、既存企業は安定期に強いことが多い。新規参入者が強いのは、モデル自体が変化している時です。

AIの時代は、そのようなシフトのひとつです。

Confluence にとって特に難しい理由

Confluence はパワフルですが、古い世界観から来ています。チームスペース、ページ、階層ナビゲーション](https://support.atlassian.com/confluence-cloud/docs/use-spaces-to-organize-your-work/) とプラグインリッチエンタープライズモデルを中心に構築されました。これらの選択は理にかなっていました。今でも多くの組織にとって理にかなっています。

しかし、それはまた、製品が多くの複雑さを抱えていることを意味します。エンタープライズプラットフォームがきれいに自己改革できることはめったにありません。自らの歴史と交渉しなければならないのです。

そのため、モダナイゼーションは遅くなります。不可能ではありません。ただ遅いだけです。

AI時代の要件として、よりクリーンなメタデータ、より明示的なトラスト・モデリング、よりオピニオン性の高いコンテンツ・ガバナンスが求められる場合、長年の拡張を通じて最大限の柔軟性を目指して構築されたシステムは、まとまった動きをするのに苦労することになります。

これがNotionにとって特に厄介な理由

Notionには別の問題があります。より新しく、より軽く、より柔軟だと感じます。しかし、その柔軟性が不利に働くこともあります。

Notionの強みは、ほとんど何でもページ、データベース、ノート、軽量ドキュメント、コラボレーションスペースにできることです。その柔軟性はチームにとって素晴らしいものです。コンテンツが何を意味し、どのような状態にあり、AIシステムによって信頼できるソースとして使用されるべきかどうかについての強力な保証が必要な場合には、あまり適していません。

プラットフォームが自由形式であればあるほど、後から信頼できるセマンティクスを課すのは難しくなります。

AIシステムは、構造、明示的なメタデータ、信頼性のシグナルで成長します。柔軟な汎用ワークスペースは、そのコンテンツがその種の用途に安全に使用される前に、多くの解釈を必要とすることがよくあります。

いずれも、絶望的という意味ではありません。

Confluence と Notion が適応できないと言うのは怠惰な分析でしょう。もちろん可能です。

彼らには賢いチーム、大きなリソース、強いインセンティブがあります。彼らはより多くのAI機能を出荷するでしょう。検索、オーサリングアシスト、サマリー、ガバナンス、構造化ワークフローを改善するでしょう。時が経てば、その差はかなり縮まるでしょう。

しかし、タイミングが重要です。

このようなシフトが起こるとき、多くの場合、最も早く前提を再構築しようとする者が有利になります。新しいプラットフォームは、改修をあまりしていないため、より一貫性を持って動くことができます。そのため、隙ができるのです。

それは永続的な窓ではないかもしれません。しかし、それが現実なのです。

ドキュメンテーション・プラットフォームの次の段階

次世代のドキュメンテーション・ツールは、人々がどれだけうまくページを書けるかよりも、どれだけ知識を信頼できるシステムとして管理できるかによって判断されるでしょう。

つまり、勝者はおそらく5つのことをうまくやるでしょう：

1.信頼を明示的にモデル化すること。 2.現在の知識と古い知識を区別すること。 3.AI検索をアドオンではなく、コアとなる製品表面として扱います。 4.断片化することなく、多言語および視聴者固有の知識をサポートします。 5.どのような情報を、誰に、どのような条件で提供するかを、チームがより強力にコントロールできるようになります。

これは古典的なwikiとは異なるカテゴリーです。

なぜ再出発が重要なのか

ソフトウェアにおいて、クリーンシートの製品が優位に立つ瞬間があります。

今がその瞬間です。

新しいプラットフォームは、初日から、ドキュメントは単なるページではないと判断することができます。ドキュメントは人間、エージェント、検索システム、AIアシスタントにとってアクティブな情報源なのです。その前提が、下流のすべてを変えるのです。

ConfluenceとNotionはそこに到達できます。しかし、別の時代に最適化されたシステムを変革しなければならないため、道のりは長くなります。

その変革には時間がかかります。その間に、新しいプラットフォームは、現代のナレッジ・インフラがどうあるべきかを定義する余地があります。

新しいプラットフォームの最大の利点は目新しさではありません。それは、古い思い込みが機能しなくなった瞬間に、古い思い込みから解放されることです。

*これは展望記事です。競合製品に関する主張は、2026年3月時点で公開されている製品ドキュメントや発表に基づいています。私たちは Confluence と Notion の両方を心から尊敬しています - 彼らは何百万ものチームに貢献している優れた製品です。

Rasepiアーキテクチャの内部：プラグイン、アクションガード、パイプライン

2026-03-06T00:00:00Z

ほとんどのドキュメンテーション・プラットフォームは、航空会社が "レッグルーム "について話すように、"拡張性 "について話します。技術的には存在しますが、実質的には期待はずれです。私はラセピのアーキテクチャが予測不可能になることなく、純粋に拡張可能であることを望みました：プラグインで能力を、アクションガードで制御を、そしてパイプラインで決定論的な実行を。

この投稿では、それぞれが実際のコードベースでどのように動作するかを説明します。

プラグインシステム: モジュール設計

Rasepiの全てのプラグインは、IPluginModuleを実装します。これは、プラグインが何であるか、どのようなサービスが必要か、どのようなルートを公開するかを宣言する単一のインターフェースです：

CODEBLOCK_0__

CODEBLOCK_24__は純粋なデータです。CODEBLOCK_24__は純粋なデータで、何も実行せずにプラグインを記述します：

コードブロック_1__

CODEBLOCK_25__に注目してください。この辞書は、フロントエンドの拡張ポイントをコンポーネント名にマップします。これにより、Vueフロントエンドは、各プラグインがどのUIコンポーネント（ツールバーのボタン、サイドバーのパネル、設定ページ）に寄与するかを知ることができます。

登録はプラグインごとに1行です。

起動時に、流暢なAPIを通じてプラグインを登録します：

codeblock_2__

それぞれの呼び出しはモジュールをインスタンス化し、レジストリに保存し、RegisterServices()を呼び出して依存関係を設定します。アプリがビルドされると、1行ですべてのプラグインのルートがマップされます：

CODEBLOCK_3__

プラグインは/api/plugins/{pluginId}/でスコープされたルートグループを取得し、認可が自動的に適用されます。

実際の例: Workflowプラグイン

実際のプラグインであるWorkflow & Approvalsモジュールの例を示します：

コードブロック_4__

コア・プラットフォームはWorkflowServiceやWorkflowPublishGuardを直接参照することはありません。DIコンテナを通してそれらを検出します。これがゼロカップリングの鍵です。コアアプリはプラグインのコードに触れることはありません。

アクションガード：コントロールレイヤー

プラグインはケイパビリティを追加します。アクションガードは、そのケイパビリティやコアのアクションが実行されるかどうかを決定します。アクションガードは同期バリデータであり、実行前に処理をインターセプトします。

アクションガードの評価フロー](/ja/blog/img/action-guard-flow.svg)

インターフェイスは意図的に最小化されています：

コードブロック_5__

CODEBLOCK_30__がnullの場合、ガードは全てのアクションに対して実行されます。それが"Entry.Publish"のように設定されている場合、その特定のアクションだけをインターセプトします。

コンテキストと結果の契約

すべてのガードは、アクション名、テナント、ユーザー、エンティティ、プロパティバッグを含む型付きコンテキストを受け取ります：

codeblock_6__

そして、すべてのガードは予測可能な結果を返します: allow、deny、またはallow-with-modificationsです：

codeblock_7。

CODEBLOCK_33__フィールドは重要です。ガードはアクションを承認しますが、コンテンツの一部を書き換えることができます(例えば、公開前に秘密を再編集するなど)。

正規のアクション名

ガードが何をターゲットにできるかについて曖昧さがないように、すべてのインターセプト可能なアクションを文字列定数として定義します：

codeblock_8__

実際の例: 承認のない公開のブロック

Workflow プラグインは Entry.Publish を阻止するガードを登録します：

コードブロック_9__

コアプラットフォームは承認ワークフローについて何も知りません。パイプラインを通してEntry.Publishを呼び出すだけで、ワークフローが完了していなければガードはそれをブロックします。

アクションパイプライン: すべてが収束する場所

CODEBLOCK_36__は全てのガードされた操作のための単一の実行パスです。CODEBLOCK_36__はどのガードが適用されるかを決定し、それらを評価し、アクションをブロックするか実行します。

CODEBLOCK_10__

CODEBLOCK_37__メソッドは重い仕事をします：

コードブロック_11__

ここで3つの重要な設計上の決定があります：

1.1. テナントごとの解決. TenantPluginResolverは、各テナントがどのプラグインをインストールして有効にしているかをチェックします。無効なプラグインのガードは決して実行されません。 2.All-must-pass. ガードが拒否された場合、アクションはブロックされます。これは意図的なセキュリティスタンスです。 3.**ガードが例外をスローした場合、それはログに記録され、Allow()として扱われます。これは壊れたプラグインがプラットフォーム全体をロックするのを防ぎます。

テナントごとのプラグイン解決

リゾルバはTenantPluginInstallationsテーブルをクエリします（EFグローバルクエリフィルタによって現在のテナントに自動的にスコープされます）：

CODEBLOCK_12__

イベント駆動型の副作用

アクションは同期です。副作用は同期ではありません。アクションが完了すると、サービスはドメインイベントを発行します：

コードブロック_13__

イベントはメモリ内のチャネルにエンキューされ、バックグラウンドの EventConsumerWorker によって処理されます。ワーカーは複数のシステムにイベントをルーティングします：

アクティビティトラッキング。
Translation billing. プロバイダごとのコストを追跡します。
プラグインのイベントハンドラ。

プラグインイベントハンドラはIPluginEventHandlerを実装しています：

コードブロック

Worker は、そのテナントでプラグインが有効になっているハンドラのみを呼び出します。つまり、プラグイン A の副作用が、プラグイン B しかインストールされていないテナントに漏れることはありません。

ブロックレベルの翻訳エンジン

このアーキテクチャーが最も目に見えて効果を発揮するのはここです。

ブロックレベル翻訳：変更されたブロックだけが再翻訳されます](/ja/blog/img/block-translation.svg)

従来のプラットフォームでは、文書全体を翻訳していました。私たちは、段落、見出し、リスト項目など、個々のブロックを翻訳します。ユーザーが50ブロックの文書の1つの段落を編集すると、その段落だけが再翻訳を必要とします。これが94％のコスト削減の源泉です。

TipTap JSONからのブロックの作成方法

ユーザーがドキュメントを保存すると、TipTapエディタは次のようなJSONを送信します：

codeblock_15__

CODEBLOCK_43__はこのJSONを解析し、個々のEntryBlockレコードを作成します：

コードブロック_16__

古いレコードを検出するためのSHA256ハッシュ

コンテンツハッシュは古さ検出の中核です。ブロックの内容（blockIdやdeletedのようなメタデータ属性を取り除いた後）をSHA256を使ってハッシュします：

コードブロック_17__

ソースブロックが変更されると、そのハッシュも変更されます。そして、システムはすべての翻訳ブロックのSourceContentHashと現在のソース・ハッシュを比較し、不一致はStaleとマークされます：

コードブロック

構造適応

翻訳者は言語間でブロックタイプを変更することができます。英語の箇条書きリストはドイツ語の番号付きリストになるかもしれません。システムはこれを追跡します：

コードブロック_19__

プラグインとしての翻訳プロバイダ

外部の翻訳サービス（DeepL、Google Translateなど）は、ITranslationProviderPluginを通してプラグインします：

コードブロック

バッチメソッドは、コンテンツへのブロックIDの辞書を受信し、それらをすべて翻訳し、課金文字数とともに翻訳を返します。ドキュメント全体ではなく、古くなったブロックだけを送信するので、コストは最小限に抑えられます。

テナントの分離: 見えないセーフティネット

上記の全てのシステムは厳格なテナント分離の中で稼働しています。

CODEBLOCK_50__はリクエスト毎にJWTからテナントを解決し、メンバーシップを検証します：

CODEBLOCK_21__

Entity Frameworkのグローバルクエリフィルタは、開発者がテナントによるフィルタリングを忘れても、データベースレイヤーが自動的に行うことを保証します：

コードブロック_22__

結果はCODEBLOCK_51__は常に現在のテナントのハブだけを返します。データ・リークには、クエリ・フィルターを積極的に回避する必要がありますが、私たちのコードベースではこれを禁止しています。

全体像

ユーザーがエントリーの "Publish "をクリックすると、次のようなことが起こります：

1.**認証がJWTを検証し、TenantContextMiddlewareが解決してテナントを検証します。 2.**コントローラがパイプラインを呼び出します。 3.**テナントが有効にしているプラグインを照会し、該当するガードを選択します。 4.**ワークフローガードは承認をチェックし、保持ガードはポリシーをチェックし、ルールガードはコンテンツを検証します。すべてパスしますか？エントリが公開されます。 5.**CODEBLOCK_54__ イベントがエンキューされます。バックグラウンドワーカーはアクティビティを記録し、翻訳課金を更新し、プラグインイベントハンドラを呼び出します。 6.**ブロックの翻訳がチェックされます。

各レイヤーは自分の仕事をします。どのレイヤーも他のレイヤーには届きません。それがアーキテクチャです。

拡張性が流行っているから作ったのではありません。各チームのワークフローに適応できないドキュメントプラットフォームは、いずれ適応できるものに取って代わられるからです。そして、ガードレールなしで適応するプラットフォームは、いずれ重要な何かを壊してしまうでしょう。