TCDEV Blog

LLMは英語で考えましょう

2026-04-27T00:00:00Z

あなたはドイツチームのためにチャットボットを出荷します。UIはドイツ語です。ソースドキュメントの一部はドイツ語、一部は英語です。アシスタントの背後にあるツールは、英語の列挙値、英語の関数説明、英語の製品名、すべてを期待しています。

そして、誰かがドイツ語でごく普通の質問をすると、モデルは適切なツールを選択し、英語の代わりにドイツ語で1つの引数を渡します。

私はこのようなバージョンを何度も見てきたので、もはや翻訳の問題だとは思っていません。**実行の問題です。

私の現在のデフォルトはシンプルで、ユーザーに好きな言語を話させ、LLMに検索、推論、ツール作業を英語で行わせるというものです。そして、そのループの外側で答えをローカライズします。

最初は少し異端に聞こえるかもしれません。私の意見では、今できる最も実用的なことです。

研究は声高にこう言い始めています

数字はもう微妙ではありません。

MASSIVE-Agentsベンチマーク](https://aclanthology.org/2025.findings-emnlp.1099/)では、52言語、47,020サンプル、21モデルで多言語関数呼び出しを評価しました。全言語の平均スコアの最高はわずか34.05%でした。英語は57.37%でした。アムハラ語は6.81%に落ちました。

これは小さな品質のぐらつきではありません。信頼性の崖です。

次に、Lost in Executionがあります。これは実際のシステムの問題にさらに近づいたものです。この論文は、多言語ツール呼び出しの失敗の多くが、モデルがすでに意図を理解し、正しいツールを選択した後に起こることを示しています。支配的な問題は、パラメータ値の言語の不一致でした。平たく言えば、モデルは何をすべきかを知っていたが、実行可能なビットをインターフェース言語ではなくユーザーの言語で表現したため、呼び出しに失敗したということです。

これはツール呼び出しに限ったことではありません。Etxanizたちは、Do Multilingual Language Models Think Better in English?で、5つのタスクにおいて、英語への自己翻訳が英語以外の直接推論よりも一貫して優れていることを発見しました。彼らの言い回しは、「英語以外の言語でプロンプトが出された場合、モデルは多言語の可能性をフルに活用することができない」というもの。

そう、多言語モデルは素晴らしい。しかし、「かなり良さそうだ」ではなく、「本番で正しく動作する必要がある」という基準であれば、英語がより安全な動作言語であることが非常に多いのです。

同じ場所でRAGが壊れる理由

この議論を聞いた人は、まずエージェントを思い浮かべるでしょう。関数の呼び出し、構造化された出力、APIの実行、そういったものです。

RAGにも同じ弱点があります。

検索レイヤが、一貫性のない用語、翻訳された商品名、中途半端にローカライズされたタクソノミーラベルなど、様々な言語で書かれたコンテンツに対して、ユーザのローカルな言い回しをマッチングさせなければならない場合、生成が始まる前にシステムがドリフトする可能性が高まります。正直なところ、「モデルが信頼できない」という不満の多くはここから来ています。モデルは問題ないかもしれません。コンテンツ・インターフェースはそうではありません。

私はむしろ早期に正規化することを望みます。

質問を英語に翻訳。英語の正規コーパスに対して検索。1つの安定した専門用語レイヤーをモデルに推論させます。必要であれば、英語の回答ドラフトを生成します。その後、ユーザーのために最終的な回答を翻訳またはローカライズします。

これで、ネーミングが安定した1つの場所になります：

正規の文書タイトル
正規の製品語彙
正規のツール・スキーマ
検索ラベルの正規セット

外部ですべてのユーザー言語をサポートすることはできます。コアとなる実行パスに、すべてのステップで完全に多言語であることを求めるのをやめるだけです。

これは反ローカリゼーションではありません

正反対です。

悪質な多言語AIアーキテクチャは通常、ローカルユーザーを最初に傷つけます。素敵なローカライズされたインターフェイスを手に入れた後、その下に隠された英語中心のシステムが矛盾した振る舞いをし、その代償を払わされるのです。

適切なローカライゼーションとは、言語が柔軟になるべきところとそうでないところについて、正直であることを意味します。

私の場合、その分かれ目は次のようなものです：

UI、プロンプト、ヘルプテキスト、オンボーディング、最終的な回答をローカライズします。
市場で存在する必要があるコンテンツは、人々が直接読むソースコンテンツをローカライズします。
内部ツールの定義、正規識別子、検索ラベル、推論ピボットは、それが最も安定したレイヤーであれば、英語のままにしておきます。
ローカライズされた出力が法的、規制的、または契約上の重みを持つ場合は、明示的な後処理または人間によるレビューを追加します。

この最後のポイントは、チームが認めたがっている以上に重要です。モデルが人間と会話している場合、ローカライゼーションはユーザーエクスペリエンスの決定です。モデルが他のシステムと会話する場合、言語はインターフェイス契約です。

これらは同じものではありません。

私が今最も信頼しているアーキテクチャ

これは、多言語AI製品のために今日私が賭けるバージョンです：

1.1.ユーザーは自分の言語で質問します。 2.システムはそのリクエストを英語に翻訳または正規化します。 3.検索、推論、ランキング、ツール呼び出しは、英語の正規データに対して発生します。 4.最終的な回答はユーザーの言語にローカライズされます。 5.高リスクの出力は、システムを離れる前に余分な検証ステップを取得します。

それは哲学的に純粋ではありません。運用上はまともです。

素晴らしいことに、最近の研究も同じ方向を示しています。Lost in Executionは、ユーザークエリを事前に翻訳することで、英語レベルのパフォーマンスを完全に回復させることはできなかったとしても、一般的に、その場限りの修正よりも言語のミスマッチエラーを減らすことができることを発見しました。これは、すでに多くのビルダーが実際に疑っていることと一致します。多言語の不一致を解消するのを最後まで待つと、たいていは手遅れになります。

そして、例外もあります。低リソース言語、ドメイン特有の言語、文化に依存した言い回しのために構築する場合、すべてを英語に翻訳するとドリフトが発生する可能性があります。上記の論文では、その点について明確に警告しています。ですから、これをドグマにしてはいけません。

しかし、企業のコパイロット、社内アシスタント、多言語RAG、ツールを使用するエージェントのデフォルトとして、このルールは驚くほどうまく機能すると思います。

これがラセピにとって意味すること

これこそが、私が正規化されたコンテンツ構造にこだわる理由です。

もし、知識ベースが1つのクリーンなソースレイヤー、安定した用語集、管理されたローカライゼーションの上にあれば、AIは信頼しやすくなります。すべての言語バージョンが実行パスの中で独立して漂うなら、システムが正確であるべきところで、モデルに即興を求めることになります。

ラセピのアプローチ全体は、これらの懸念をきれいに分離することに基づいて構築されています。標準的なコアを維持します。意図的にローカライズします。バリアントが存在する場所を追跡します。UIが多言語だからといって、スタックのすべてのレイヤーが同じように多言語であるかのように装わないでください。

私は以前、最高の多言語AIエクスペリエンスとは、"ユーザーの言語ですべてを行う "ことだと思っていました。しかし、今はそうは思いません。正しい段落を取得し、正しいツールを選択し、信頼できるものを返さなければならないシステムのためではありません。

しかし、LLMの実行パスは安定していなければなりません。今現在、それは通常、真ん中では英語、端ではローカライズを意味します。

それは時間とともに変わっていくでしょう。早く変わることを願っています。しかし、もしあなたが今日出荷していて、美しさよりも信頼性の方が重要なのであれば、私はモデルに英語で考えさせ、製品にユーザーの言語をしゃべらせます。

クロード・デザインと一人クリエイティブ・エージェンシー

2026-04-18T00:00:00Z

昨日、AnthropicはAnthropic Labsチームの新製品であるClaude Design(https://www.anthropic.com/news/claude-design-anthropic-labs)を発表しました。Claudeと話すことで、デザイン、プロトタイプ、プレゼンテーション、マーケティング資料を作成することができます。クロードのサブスクリプションを持つ一人の人間が、小さなクリエイティブエージェンシーが提供するもののほとんどを純粋に手に入れることができるのです。デザイン。コード。自動化。プレゼンテーション。ブランドの一貫性。すべて同じエコシステム内で。

2026年に書くには乱暴な文章です。しかし、私はそれが誇張だとは思いません。

クロード・デザインが実際に行っていること

簡単に言うと、あなたが必要なものを説明し、クロードが最初のバージョンを作ります。その後、会話、インラインコメント、直接編集、またはClaudeがあなたのために生成するカスタムスライダーを通して改良します。これはOpus 4.7で動作し、驚くほど視覚的な一貫性を維持します。

しかし、私が注目した機能はオンボーディングです。セットアップの際、Claudeはあなたのコードベースと既存のデザインファイルを読み込み、チームのためのデザインシステムを構築します。色、タイポグラフィ、コンポーネント。その後、すべてのプロジェクトは自動的にあなたのブランドに従います。画像やドキュメント（DOCX、PPTX、XLSX）をインポートしたり、コードベースを直接参照することもできます。ウェブキャプチャツールがあり、実際のウェブサイトから要素を取り込むので、プロトタイプが実際の製品のように見えます。

Figmaのモックアップを作成しましたか？それをエクスポートしてクロード・デザインにドロップし、何を変更するかについて会話を始めましょう。あるいは、既存のウェブサイトをキャプチャして、「ヒーローセクションを大きくして、お客様の声のカルーセルを追加してください。そんな感じです。

この発表で語られた体験談は示唆に富んでいます。Brilliantのシニアプロダクトデザイナーは、他のツールで再現するのに20以上のプロンプトが必要だった最も複雑なページが、Claude Designでは2プロンプトで済んだと述べています。Datadogのプロダクトマネージャーは、誰もが部屋を出る前にラフなアイデアから実用的なプロトタイプに到達することを説明し、以前はブリーフ、モックアップ、レビューラウンドに1週間かかっていたものが、今では1回の会話で済むようになったと述べています。

1週間のやりとりが、たった1回の会話で終わるのです。ちょっと考えてみてください。

すべてを変えるスタック

ここからが面白いところです。クロード・デザインは単独では存在しません。Anthropicには現在3つの製品があり、それらを組み合わせると、とんでもない量の領域をカバーすることができます：

クロード・コード**：実際のソフトウェアを書き、レビューし、出荷します。ランレート収益25億ドル(2月現在)、全世界のGitHub公開コミットの推定4%を担当。
クロード・コワーク**：ナレッジワークの自動化。調査、分析、文書処理、デスクトップからの定期的なタスク。
クロードデザイン**：ビジュアルワークを作成します。プロトタイプ、プレゼンテーション、マーケティング資料、ブランド一貫性のある資産。

そして、互いに譲り合います。デザインの構築が完了すると、Claudeはすべてをハンドオフバンドルにパッケージ化し、1回の指示でClaude Codeに渡すことができます。デザインから制作までワンフローで。Jiraチケットなし。ハンドオフミーティングなし。"Slackで仕様書を送ってくれ "もありません。

2024年初頭のサム・アルトマンの一人で10億ドルを稼ぐ企業についての予測をずっと考えています。当時は、少し大げさかもしれませんが、願望的に聞こえました。ツールはまだありませんでした。確かにテキストや画像を生成することはできましたが、モノを生成することと実際の製品を出荷することの間には大きな隔たりがありました。

そのギャップは急速に縮まっています。

2ヶ月前ならこのために何を捧げたか

ラセピを作った時、マーケティングサイトは最も面倒な部分の一つでした。コードではありません。クロードは HTML と CSS をチャンピオンのように扱います。しかし、ビジュアルデザインの決定は？ヒーローのレイアウト、価格ページのカード、機能比較表？私が言葉で説明し、クロードが何かを作成し、私は何時間もかけて、間隔、色、タイポグラフィを調整するために行ったり来たりしました。すべてテキストプロンプトで。視覚的なフィードバックのループがありません。

クロード・デザインでは、そのワークフローは次のようになります：「これが私のウェブサイトです」（ウェブキャプチャ）、「チームプランを強調するために価格セクションを再設計してください」（会話）、スライダーで緑のアクセントカラーを調整し、承認し、実装のためにクロード・コードに引き渡します。これで週末を丸々節約できたと思います。

(正直なところ、2カ月も早く立ち上げられなかったことが少し悔やまれます）。

そして、Canvaのエクスポートは賢い。Canvaのアクティブユーザー数は2億2000万人で、年商は30億ドル。AnthropicはCanvaに取って代わろうとしているわけではありません。AnthropicはCanvaに取って代わろうとしているわけではありません。これは賢いポジショニングです。あなたはClaude Designでクリエイティブを作成し、Canvaにエクスポートして、マーケティングチームがそれをピックアップします。または、投資家デッキ用にPPTXにエクスポートします。または、ランディングページ用のスタンドアロンHTMLとしてエクスポートします。

ツールを追加するだけ」の倍率

これは、2026年のAIの分野で私がよく目にするパターンです。ベースモデルがより賢くなるのは確かですが、生産性を飛躍的に向上させるのは、ツールをつなげることによってもたらされます。Claude単体は非常に賢いテキストジェネレーターです。Claude with Codeはソフトウェア・エンジニア。CoworkのClaudeはリサーチアナリスト。ClaudeとDesignはクリエイティブディレクター。Claudeが3つ全部？それは小さなエージェンシーです。

そして、つながりは増え続けています。Anthropicは、今後数週間でさらに統合機能を追加する予定だと述べています。MCPサーバーはすでにクロードを外部のツールやデータソースに接続することができます。エコシステムが構築されつつあるのです。

単独の創業者、フリーランサー、小さなチームにとって、これは完全に計算を変えます。プロフェッショナルなデッキやプロトタイプを作るために、デザイナーを雇う必要はありません。モックアップをコード化するためにフロントエンド開発者を別途雇う必要もありません。デザインとエンジニアリングの間を取り持つプロジェクトマネージャーも必要ありません。それは、ひとつの継続的な会話だからです。

デザイナーが時代遅れだと言っているのではありません。そうではありません。Brilliant社とDatadog社は、クロード・デザインを使用している*デザイナーについて説明しています。このツールは優秀なデザイナーをより速くし、他の誰もが有能な視覚的アウトプットにアクセスできるようにします。それは人を置き換えることとは別のことです。

ドキュメンテーション製品にとっての意味

これは私が注視していることです。ラセピでは、視覚的な品質が重要なドキュメントプラットフォームを構築しています。エントリーページは美しくなければなりません。クイックスタートガイドには明確な図が必要です。マーケティングドキュメントには、言語やチームを超えたブランドの一貫性が必要です。

すべてのチームメンバーが、Figma や Photoshop、InDesign に触れることなく、ブランドのビジュアルドキュメントを作成し、翻訳エンジンに渡し、7 か国語で配布できる世界。それこそが、私たちが別の角度から解決しようとしている問題です。(そして、これこそが、Rasepi がサポートするワークフローなのです。）

変に高くつくところ

ここでまだ誰も話していないことがあります。私はクロードデザインを試すために特別に新しいAnthropicアカウントを作りました。新しいアカウントで、履歴も使用歴もありません。小さなFigmaファイルを1つインポートし、アセットを1つ作成しました。それだけです。2つの操作。そして、クレジットを使い果たしました。

新しいアカウントで。新しい割り当てで。

Opus4.7がビジュアル生成を行っているとき、Anthropic側のトークン計算がどうなっているのか分かりませんが、それが何であれ、「一人でできるクリエイティブエージェンシー」という売り込みが予想以上に高く感じられるペースでクレジットを消費します。小さなFigmaのモックアップをインポートして、1つの画像を作成するのに全予算を費やすのであれば、これを日常的なデザインツールとして使用する経済性は、まだ機能しません。

公平を期すために、これはリサーチ・プレビューであり、価格はおそらく変更されるでしょう。しかし、現時点では、約束（デザインワークフローを置き換える）と現実（昼食前にクレジットを使い果たすかもしれない）の間に意味のあるギャップがあります。生産性の向上は本物です。アウトプットあたりのクレジットの比率が、通常の使用に実用的かどうかはまったく別の問題です。

正直な注意点

クロード・デザインは研究段階のプレビューです。荒削りな部分があるでしょう。これらの証言は、確立されたデザインシステムを持つ、資金力のある企業のデザインチームによるものです。特に、ブランドガイドラインを持たずにゼロから始める場合、あなたの走行距離は異なるでしょう。

しかし、軌跡は明らかです。1年半前は、コンセプトからランディングページの完成まで、デザイナー、デベロッパー、プロジェクトマネージャーが必要でした。今日では、クロードのサブスクリプションを持つ一人の人間が、同じワークフローの驚くほど信頼できるバージョンを午後に行うことができます。

私たちはまだ、一人で10億ドル規模の会社を設立しているわけではありません。しかし、一人でできるクリエイティブ・エージェンシー？私たちは今、到着したところだと思います。

1つのAPIキー、多数のテナント：顧客間でDeepL翻訳を分離する方法

2026-04-18T00:00:00Z

Rasepiの翻訳アーキテクチャを他の開発者に説明するたびに出てくる質問があります。すべてのテナントが1つのDeepL APIキーを共有しているのですか？

これは正しい質問です。その答えには、予想以上に多くの設計作業が含まれます。

ブロックレベルのハッシュ化、オーケストレーター、ドキュメントの保存から翻訳された出力までの全体の流れなど、完全な翻訳パイプラインについては以前の投稿で取り上げました。この投稿では、マルチテナンシーという特定の問題にズームインします。テナントの概念を持たないサードパーティAPIをどのように利用し、その上にテナント分離を構築するか。

問題：DeepLはあなたの顧客について知らない

DeepLのAPIは、単一のAPIキーで認証されます。そのキーの下で作成されたすべてのもの、用語集、スタイルルールリスト、翻訳履歴は、同じアカウントに属します。DeepL側には、"この用語集はテナントAに属する" という概念はありません。

CODEBLOCK_2__ を呼び出すと、すべてのテナントからすべての用語集が取得されます。スタイル・ルール・リストを作成すると、それは他のすべてのテナントのスタイル・ルールと同じネームスペースに存在します。APIはフラットです。

すべての顧客が独自の DeepL キーで独自のインスタンスを実行するセルフホスト型製品の場合、これは問題ありません。当社がインフラストラクチャを管理するマルチテナント型SaaSの場合は?分離レイヤが必要です。

データベースは真実のソースです。

私たちの中核となる設計上の決定：**データベースは、すべての用語集コンテンツおよびスタイル・ルール構成を所有します。DeepL は実行時のターゲットであり、それ以上ではありません。

すべてのTenantGlossaryおよびTenantStyleRuleListエンティティはITenantScopedを実装しています。これは、EF Coreグローバル・クエリ・フィルタがすべての読み取りを現在のテナントに自動的にスコープすることを意味します。テナントAのリクエストコンテキストにある用語集に対するクエリは、テナントBのエントリを決して返しません。これはORMレベルで強制される、Rasepiのあらゆる場所で使用している同じ分離パターンです。

これが興味深い点です。テナントが用語集を編集しても、すぐにDeepLを呼び出すわけではありません。データベースの行を更新し、IsDirty = trueを設定します。これだけです。実際の DeepL 用語集は、次の翻訳で必要になる直前に、遅延的に作成 (または再作成) されます。

CODEBLOCK_0__

CODEBLOCK_7__ のクエリ・フィルタが分離を行います。CODEBLOCK_8__フラグが遅延同期を行います。また、命名規則 (rasepi-{glossary.Id}) は、DeepL ダッシュボードでのデバッグのためだけであり、機能的な目的はありません。

遅延の理由DeepL v2 用語集は不変](https://developers.deepl.com/docs/api-reference/glossaries) だからです。編集できません。変更は、削除と再作成を意味します。チームが 200 の用語を含む CSV をインポートし、1 つのエントリでタイプミスを修正した場合、DeepL 用語集を 2 回削除して再作成する必要はありません。この場合、IsDirty を 2 回とも設定し、次の翻訳の実行時に 1 回だけ再作成します。

スタイル・ルール: 同じパターン、異なる API

DeepL のスタイル・ルールはより新しく (v3 API) 、実際に変更可能です。CODEBLOCK_11__を使用すると、構成済みのルールをその場で更新でき、カスタム命令を個別に追加または削除できます。

しかし、同じIsDirtyパターンを使用しています。CODEBLOCK_13__ には、DeepL の実行時識別子にマップされる DeepLStyleId と、書式設定ルール用の ConfiguredRulesJson 、およびフリーテキスト翻訳ディレクティブ用の TenantCustomInstruction エントリのコレクションがあります。

本当の力はこれらのカスタム命令にあります。各命令は、DeepL の翻訳方法を形成する最大 300 文字のプレーン・ランゲージ命令です。テナントからの実際の例：

常に'Sie'形式を使用し、決して'du'を使用しないでください」_ドイツの法律事務所向け
deployment'を'Bereitstellung'と翻訳し、決して'Deployment'とは翻訳しない」_単純な用語集のマッピングを超えるコンテキスト依存の用語の場合
英国の会社では、英語の表記を使い分ける必要があります。
通貨記号を数字の後に付ける」_欧州の慣習のため

各テナントは、ターゲット言語ごとに完全に異なる命令を持つことができ、すべて同じAPIキーの背後にあります。すべての翻訳呼び出しには、要求元のテナントに属するglossary_idとstyle_idのみが含まれるため、隔離されます。他のテナントの DeepL リソースが参照されることはありません。

翻訳呼び出し: すべては

オーケストレータがブロックを変換するとき、すべてのテナント固有の設定を 1 つの要求にまとめます：

codeblock_1__

ここにあるすべてのパラメータはテナントにスコープされています。CODEBLOCK_19__はテナントフィルターされたクエリで解決されました。CODEBLOCK_20__も同様に解決されました。CODEBLOCK_21__はTenantLanguageConfigから来ており、これもテナント・スコープされています。CODEBLOCK_23__（翻訳品質を向上させるために送信された段落を囲むもので、課金対象ではありません）も、テナント自身の文書から来たものです。

強調したいことが 1 つあります。style_id が設定されると、DeepL は自動的に quality_optimized モデルを使用します。スタイル・ルールと latency_optimized を組み合わせることはできません。これは DeepL の制約ですが、正直なところ妥当な制約です。カスタム・スタイル・ルールに投資する場合は、おそらく最高品質の出力が必要です。

ブロックレベルのキャッシュ: 翻訳メモリとしてのデータベース

変更のないブロックに対して DeepL を呼び出すことはありません。キャッシュ・メカニズムは、TranslationBlock テーブルそのものです。

すべてのソースEntryBlockには、ContentHashがあります。これは、意味的コンテンツのSHA256です (blockIdやdeletedなどのメタデータ属性は除去されています)。すべてのTranslationBlockは、その変換が行われた時のSourceContentHashを格納します。ソースブロックが変更されると、そのハッシュも変更されます。オーケストレータはハッシュを比較し、不一致のあるブロックだけをキューに入れます。

各ブロックのデシジョンツリーは次のようになります：

1.ハッシュが一致し、翻訳が存在する = スキップ (キャッシュ、最新) 2.ハッシュが変更、機械翻訳、ロックされていない = 自動的に再翻訳 3.ハッシュが変更された、人間が編集した、またはロックされた = 古いとマーク、上書きしない

この3番目のケースが重要です。ドイツ語翻訳者が手作業で段落を修正した場合、英語ソースが変更されたからといって、その段落を削除することはありません。ドイツ語翻訳者にレビューが必要であることを認識させるために、staleとしてフラグを立てますが、翻訳されたテキストはそのまま残ります。

実際の結果: 30 段落のドキュメントの 1 つの段落を編集すると、DeepL API 呼び出しがちょうど 1 回呼び出されます (ただし、1 つのブロックを含む 1 つのバッチ)。他の 29 の段落は、すべての言語にわたって、すでにキャッシュされており、コストはかかりません。

テナントごとに別のキーを使用しませんか?

真剣に検討しました。各テナントに独自のDeepL APIキーを与えれば、分離の問題は完全になくなります。

そうしなかった3つの理由：

1.**すべてのテナントに独自の DeepL サブスクリプションまたはサブアカウントをプロビジョニングする方法が必要です。DeepL は、マルチテナント鍵管理をネイティブで提供していません。 2.**インフラストラクチャの共有は、料金の上限とボリューム割引の共有を意味します。当社の使用量を合計することで、より良い価格設定が可能になります。 3.**ローテーションするキーは1つ、監視するクォータは1つ、保守する統合は1つです。

トレードオフは、私が説明した分離レイヤーが必要だということです。しかし、システム内の他の全てのものに対して既にテナント・スコープのEF Coreクエリを持っていることを考えると、用語集やスタイル・ルールにそれを追加することは簡単でした。パターンはすでにそこにありました。

実際にあなたを守るもの

分離保証をまとめると

用語集エントリ** は TenantGlossary (ITenantScoped の実装) に格納され、EF Core のグローバル・クエリ・フィルタによってフィルタリングされます。DeepL 用語集 ID は、テナント・コンテキスト内でのみ解決される不透明な参照です。
スタイル・ルールおよびカスタム命令**は、TenantStyleRuleListを通じて同じパターンに従います。
翻訳されたコンテンツ**はTranslationBlockにあり、親であるEntry → Hubチェーンを経由してスコープされます。
CODEBLOCK_40__ガード**は、新しいエンティティに自動的にTenantIdを設定し、クロステナント書き込み時にスローします。
本番コードではIgnoreQueryFilters()**を使用しません。これまで

設計原則は単純です：DeepLはリソースIDを見ます。Rasepiはテナント・スコープのエンティティを参照します。マッピングを解決するクエリは物理的に別のテナントのデータを返すことができないため、両者間のマッピングがテナントの境界を越えることはありません。

ネイティブのテナントサポートを持たないサードパーティAPIと統合するマルチテナントSaaSを構築する場合、このパターンはうまく機能します。外部APIをステートレスな実行エンジンとして扱い、全てのコンフィギュレーションを独自のテナント・スコープ・データベースに保持し、遅延同期を行い、分離のために外部リソース・リストを決して信用しないようにします。

トークンバーニングは新しいコード行数です。

2026-04-13T00:00:00Z

私のLinkedInのフィードは、この数週間、技術用語でいっぱいです。私のXのタイムラインも。トークンを使ったスクリーンショットを進捗報告のように投稿する人たち。先月クロードコードに1万6千ドル使って、次は6万ドルを目指すと自慢するスタートアップの創業者たち。リーダーボード。ランキング。"トークン伝説 "や "AI神 "のような称号。

そして先週、それは臨界点に達しました。フォーブスは、シリコンバレーを席巻している "tokenmaxxing "ムーブメント(https://www.forbes.com/sites/richardnieva/2026/03/31/the-ai-gods-spending-as-much-as-they-can-on-ai-tokens/)について報道しました。ジェンセン・フアンはAll-Inのポッドキャストに出演し、次のように述べました：その50万ドルのエンジニアに、年末に『トークンでいくら使ったの？もしその人が『5,000ドル』と答えたら、私は別のことをします。その50万ドルのエンジニアが少なくとも25万ドル相当のトークンを消費していなければ、私は深く憂慮します」_。

その後フォーチュンは、メタ社の社員が社内のリーダーボード「クロードノミクス」を構築し、同社の85,000人以上の社員全体のトークン消費を追跡していたことを報告。トップユーザーには称号が与えられます。30日間で、総使用量は60兆トークンに達しました。個人ユーザーのトップは平均2,810億。マーク・ザッカーバーグはトップ250にも入りませんでした。一方、MetaのCTOであるアンドリュー・ボスワース氏は、彼の最高のエンジニアは、彼の給料に相当する額をトークンで使っているが、"5倍から10倍生産性が高い "と公言していました。「ボズワース氏は、「これは簡単なお金です。"上限なし"

私はソフトウェアに長く携わっているので、ここで何が起きているのか理解できます。これは "コードの行数 "であり、値段はもっと高い。

We've been here before

2003年、マーティン・ファウラーはなぜソフトウェアの生産性は測定できないのかについての短い文章を書きました。コード行数に関する彼の議論は的確でした：

私の最大の苛立ちの一つは、コード行数に基づく生産性の研究です。優秀な開発者なら誰でも、同じものをコーディングしてもコード行数に大きな差があることを知っています。"

この問題は、口に出して言ってみれば明らかです。LOCはアクティビティを測定するのであって、アウトプットを測定するのではありません。2人の開発者が同じ機能を作ることができます。1人は1,200行書き、もう1人は80行書きます。一方は1,200行書き、もう一方は80行書きます。LOC体制下では、冗長な方がより生産的に見えます。

LOCで評価されたチームは合理的に反応しました。彼らはより多くの行を書きました。抽象化するよりもコピーペースト。コードを削除すると数が減るので、リファクタリングを避けました。この評価基準は行動を形成しましたが、より良いソフトウェアに向かうものではありませんでした。より多くのコード。より悪いシステム。

そして2023年、McKinseyは客観的な開発者の生産性測定を解明したと主張する記事を発表しました。Gergely OroszとKent Beckの徹底的な反論は、同じ欠陥を指摘しました。ほぼすべてのマッキンゼーの指標は、成果ではなく、努力とアウトプットを測定していたのです。ケント・ベック氏は、フェイスブック社内の開発者センチメント調査が、有益なフィードバックから、より高いスコアを得るために管理職がエンジニアと交渉するようになるのを見てきたと語りました。代理指標にインセンティブを与えるとこうなります。数値は向上します。あなたが実際に気にかけていたことは改善されません。

私たちは学んだはずです。私たちは学んでいません。

同じ過ち、異なるユニット

トークン・マックスの魅惑的な論理はこうです。トークンの消費＝AIの使用AIの使用率が高い＝チームがAIを使用しているしたがって、トークンの消費が多い＝AIの普及率が高い＝良いこと。

これは、コミットグラフの代わりに課金ダッシュボードを使うだけで、コード行数を測定するのと同じような欠陥があります。そして、フォーブスの記事に対して公平であるように、SendbirdのCEOであるジョン・キムは、基本的にまさにそのように述べています：「私たちはこの映画を前に見たことがあります。彼は1990年代と2000年代のLOC文化について言及しています。本当の指標は、AIが生成したコードが実際にどれだけ生産に入るかだと彼は指摘しています。トークンの支出は、"むしろ会話のきっかけになる"」。それは同感です。会話のきっかけがKPIの見出しに昇格すると問題になります。

GitHubの2024年開発者調査によると、企業開発者の97％が、AIコーディングツールを仕事で使ったことがあることがわかりました。しかし、有意義な組織的採用には、明確なポリシー、ワークフロー、実際のビジネス成果に結びついた測定可能な成果が必要です。単なる使用ではありません。単なる消費でもありません。

Claude CodeのエンジニアであるBoris Chernyは、Opus 4.5で約200のPRを書きながら、1ヶ月の仕事の間IDEを全く開かなかったことを公に共有しています。それはすごいことです。しかし、それを印象的なものにしているのは、それらの200のPRが消費したトークンではありません。それは、200のPRが、実際に動作するソフトウェアとマージされた貢献であったということです。

価値は結果にあります。トークンはそこに到達するためのエネルギーであり、それ以上のものではありません。

評価基準が目標になるとき

グッドハートの法則と呼ばれる原則があります。ソフトウェア開発の歴史は、基本的にグッドハートの法則が作用している博物館です。

AI導入のKPIとしてトークンを追跡することは、まったく同じ力学を設定します。トークンの消費量を測定するエンジニアリングチームは、より多くのトークンを消費します。それがインセンティブというものです。より生産的に見せたいですか？もう少しエージェントループを回してください。アウトプットを生成する前に、モデルに長々と推論させましょう。すべてのタスクをオーケストレーション・レイヤーで包み込み、1つで済むところを4つのツールを呼び出します。トークンの消費は増加。提供される価値は上がりません。

実際、クロードノミクスのストーリーは、ほぼ即座にこれを証明しました。フォーチュンは、"一部の従業員は、トークンの使用量を最大化するためにAIエージェントを何時間も働かせている "と指摘しています。これです。グッドハートの法則が、AIによる生産性の最前線にいるはずの企業内で、リアルタイムで実行されているのです。リーダーボードは閉鎖される数週間前から設置され、社員はすでにエージェントをループさせてゲームをしていました。この指標は3週間前のもので、すでに測定するはずのものを測定しなくなっていました。

これを読んでいる開発者なら誰でも、トークンの使用量メトリクスを誰にも得にならないように膨らませる方法を5つ思いつくでしょう。それを列挙するつもりはありません。しかし、私が5つ思いつくのであれば、これで測定されるエンジニアも思いつくでしょう。

Andrej Karpathy氏は、ソフトウェアエンジニアリングにおける現在の瞬間を、専門職にとっての「マグニチュード9の地震」と表現しました。彼は正しい。しかし、地震は消費された電力では測られません。何が動いたかで測られるのです。

この問題のドキュメント版

これはエンジニアリングチームだけの問題ではありません。ナレッジマネジメントでも同じような動きがあります。

「今期は400のドキュメントを発行しました」というのは、スライドデッキの中では聞こえの良い数字です。しかし、それらの文書が正確かどうか、誰かが読んだかどうか、6ヶ月後もその文書に書かれている情報が正しいかどうかについては、何も語ることはできません。AIを使えば、何も考えずにこの数字を叩き出すことができます。トークンの支援によるノイズの大規模公開。

正直な指標を収集するのは難しいですが、はるかに有用です：あなたの知識ベースの何パーセントが実際にあなたのシステムが今日どのように動作するかを反映していますか？何人の人があなたのドキュメントを使って正しい答えにたどり着きましたか？何人が試行錯誤し、失敗し、代わりにSlackで誰かに聞くことになったのでしょうか？

これらの質問には、まだきれいなダッシュボードはありません。あなたの組織のためにドキュメントに何をさせたいのか、実際に考える必要があるのです。(これは、偶然ではありませんが、まさにRasepiが中心となって構築された問題です。強制的な有効期限が存在することで、高いページ数の指標の陰で黙って朽ち果てていくのではなく、コンテンツがまだ有効かどうかをチームが考えなければならないのです)

代わりに何を追跡すべきか

AIへの投資が報われているか」に対する正直な答えは、課金ダッシュボードからは読み取れません。

サイクルタイムは改善されているか？サイクルタイムは改善されていますか？エンジニアは、判断に重きを置く作業に時間を費やし、タイピングに費やす時間を減らしていると報告していますか？ドキュメンテーションは、堆積物のように蓄積されるのではなく、最新の状態に保たれていますか？

これらをAPIから引き出すのは難しい。チームから実際にどのようなアウトプットが欲しいのかを考える必要があります。しかし、これらは重要な質問であり、インプットよりもむしろ結果についてだからです。

トークンの使用量は、購入したコンピューティングの量を示します。そのコンピューティングが有用なものになったかどうかは、まったく別の問題です。この区別を維持しない企業は、ほとんど何も見せない非常に高価なダッシュボードを作ることになるでしょう。

私たちは何年もかけて、開発者の生産性に関する誤った指標を最適化してきました。同じ間違いが企業内のすべてのAI導入レポートに組み込まれるまで、あと1四半期しかありません。これを避けるための窓は開いていますが、そのままではありません。

AI の分断がチームを真っ二つに

2026-04-10T00:00:00Z

先週、友人と電話で話していたときに、ある物流会社の顧客の話を聞きました。あるチームリーダーが企画会議を開いたところ、彼女の部下2人が、会議が始まる前にAIを使ってシナリオモデル全体を構築していたそうです。予測、リスクの内訳、3つの代替アプローチ。チームの他の4人は、2年間使ってきたのと同じスライドデッキフォーマットを持って現れました。同じ構成、同じマニュアルプロセス、同じタイムラインの見積もり。

会議は早くも横道にそれました。AIアシストのペアは、「今なら5分で終わる」基本的な事前準備を、なぜ他のペアがやらなかったのか理解できませんでした。他のメンバーは、ゲームのルールが変わったのに誰も教えてくれなかったような、待ち伏せされたような気分でした。チームリーダーはその日の残りをダメージコントロールに費やしました。

その話はもう驚かないわ。もう驚かないわ。

ギャップは測定可能

これは単なる雰囲気ではありません。マイクロソフトの2025 Work Trend Indexは、31カ国の31,000人の労働者を対象にした調査で、リーダーの67%がAIエージェントに精通しているのに対し、従業員は40%に過ぎないことがわかりました。リーダーはAIをキャリア加速装置として捉える傾向がはるかに高く（従業員の67％に対し79％）、AIを活用することでより多くの時間を節約しています。リーダーの3分の1近くが、AIによって毎日1時間以上時間を節約できていると回答しています。

AIをどのように見ているかという質問に対して、回答者の52％がAIをコマンドベースのツールとして扱っていると答えています。AIに指示を与え、結果を得るのです。AIを思考のパートナー、つまり対話する相手と表現したのは46％だけでした。

これは小さな違いではありません。同じテクノロジーに対して、根本的に異なる2つの関係があるのです。そして、この2つのグループは同じ会議に出席し、同じプロジェクトに取り組み、同じ方向に進んでいるはずなのです。

2つのスピード、1つのチーム

現実的な結果として、チームは2つのまったく異なるスピードで動いています。日常業務にAIを組み込んだ人々は、単に生産速度が速くなっただけではありません。考え方も違います。問題への取り組み方も違います。以前は1週間かかっていた仕事が、午後には終わって会議に出席します。

そして、AIを導入していない人たち（あるいは、一度導入してみたものの、圧倒されるような結果に終わり、次に進んだ人たち）は、純粋に堅実な仕事をしています。そのことをはっきりさせておきたいと思います。彼らは仕事が下手なのではありません。可能性の天井が移動し、彼らは古い天井の下で働いているのです。

チームにおけるジェネレーティブAIに関するハーバード大学の研究](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5188231)は、驚くべきことを発見しました：AIを使用する一人の個人は、AIを使用しないチーム全体を凌駕します。しかし、全員がAIを使用しているチームは、AIを使用していないチームよりも優れているのです。その意味は残酷です。混合採用は中間領域を与えません。摩擦が生じるのです。

先月私が運営したワークショップで、私はこれを目の当たりにしました。AIを常用している参加者は、半分の時間で練習を終え、残りを待つのにイライラしていました。AIを使っていない参加者は、急かされているように感じ、正直、少し屈辱的でした。誰もそのような結果を意図したわけではありません。スピードの差が大きくなったので、そうなっただけです。

誰も語らない競争優位性

ここからが本当に重要なことです。マッキンゼーのState of AI 2025 surveyによると、88%の組織が少なくとも1つの機能でAIを使用していることがわかりました。素晴らしいと思いませんか？しかし、3分の2近くはまだ実験やパイロット段階にとどまっています。AIをビジネス全体に拡大し始めているのは、わずか3分の1程度です。そして、マッキンゼーが「ハイパフォーマー」と呼ぶスケールアップした企業は？回答者の約6％です。

この6%は、ほとんどの人が過小評価しているようなスピードで他の企業から引き離されています。

ハイパフォーマーは、AIを中心にワークフローを根本的に再設計している可能性が3倍高い。また、シニアリーダーがAI活用を積極的に支持し、模範を示している割合も3倍高くなっています。彼らの4分の3は、組織全体でAIを拡張しているか、すでに拡張しています。

マイクロソフトのデータも同様のことを物語っています。彼らが「フロンティアファーム」と呼ぶ企業（組織全体でAIを展開し、成熟度が進んでいる企業）は、劇的に異なる結果を報告しています。フロンティア・ファームのリーダーの71％が、自社は繁栄していると答えています。より多くの仕事を引き受けることができると答えたのは55%で、世界全体では25%です。また、AIに仕事を奪われることを恐れておらず、むしろ恐れています。

これらの企業と他の企業との差は縮まっていません。加速しているのです。

これはテクノロジーの問題に見せかけた、人の問題です。

ツールで解決しようとする誘惑。Copilotを導入し、ライセンスを購入し、AIリソースについて全社にメールを送りましょう。完了。

しかし、実際の課題は文化的なものです。チームリーダーは、半数の社員が超高速化を感じ、残りの半数の社員が取り残されたと感じているグループをまとめようとします。20年来のベテランに、10年かけて完成させたワークフローはもうベストなアプローチではないかもしれないと説明しなければならないマネージャー。AIを使ってシニアレベルの仕事を黙々とこなし、政治的な影響について誇りを持つべきか心配するべきかわからない若手社員。

マイクロソフトの調査によると、47％のリーダーが人材戦略のトップとして既存社員のスキルアップを挙げています。それは励みになりますね。しかし、スキルアップがうまくいくのは、人々が実際に学びたがっている場合だけです。そして今現在、従業員のかなりの部分が、AIは自分とは関係ない、信頼できない、努力する価値がないと判断しています。特定のツールについては正しい人もいるかもしれません。しかし、より広範な軌跡はオプションではありません（私は長年にわたって多くの技術的誇大広告のサイクルに懐疑的であった者としてそう言っていますが、今回は違うと感じます）。

この先

格差がなくなるとは思いません。格差は広がると思います。AIを採用する人は、より速く、より多くの成果を出し続け、「通常の成果」の水準を上げ続けるでしょう。そうでない人たちは、経営陣からであれ、同僚からであれ、あるいは同僚が自分にはできないことをやっているという周囲の現実からであれ、プレッシャーを感じ続けるでしょう。

熱狂的なファンだけでなく、チーム全体を巻き込む方法を見つけた企業は、真のアドバンテージを持つことになるでしょう。そして、その優位性はさらに高まります。組織としてAIを使いこなせるようになるまでの1カ月は、競合他社がChatGPTのライセンスを購入するかどうかの議論に費やす1カ月です。

AI時代の最大の競争優位性は、どのモデルを使うかではありません。チーム全体が実際にそれを使っているかどうかです。

先ほどの物流チーム？私の友人によると、チームのリーダーは2日間の社内ワークショップを予約したそうです。"どうすればいいか "ではなく。もっと言えば、"これが私たちの計画方法をどう変えるか "です。懐疑的な人たちは、でっち上げのシナリオを使った一般的なデモではなく、自分たちの*仕事の文脈で何が可能かを見る必要がありました。そして、熱狂的なファンは忍耐を学ぶ必要がありました。先走るのではなく、人々を巻き込むために。

それが今の仕事のような気がします。AIを導入するだけでなく。ギャップを埋めること。AIに閉ざされる前に。

ビルドとバイの再考：2026年の実際の意味

2026-04-07T00:00:00Z

先週、チームの若手開発者が、認証、データベース移行、中途半端なUIを備えたCRUDアプリを約90分で完成させるのを見ました。Copilotを使って。ゼロから。

5年前なら、同じ作業に1週間はかかったでしょう。デプロイ設定やOAuthフローのヤク削りを入れれば2週間かもしれません。そして、このシフト、数日から数時間への構築時間の圧縮は、ソフトウェアにおける最も古い疑問の1つを静かに解体しています。

古い枠組みは死んだ

何十年もの間、「作るか買うか」はコスト計算でした。あるものを構築するのにどれだけの開発者月数がかかるかを見積もり、それに給与を掛け合わせ、メンテナンスのためのバッファを追加し、ほぼ同じことができるSaaS製品の年間ライセンス料と比較するのです。SaaSの方が安ければ、それを購入。要件が十分に奇妙であれば、構築。

その枠組みは、構築にはコストがかかるという前提でした。実際そうでした。しかし、GitHubのOctoverse 2025のデータによると、AI支援による開発は現在、スループットを20～30％向上させています。GitHubでは、新規開発者の80％が最初の1週間以内にCopilotを利用しています。110万以上のパブリックリポジトリがすでにLLM SDKを統合しています。ほぼ一夜にして、ビルドが劇的に安くなりました。

ですから、問題はもう「ビルドか購入か」ではありません。SaaSを購入するとき、実際には何にお金を払っているのか？

新しい微積分

正直なところ、私も含めて）ほとんどのSaaS創業者は聞きたくないことだと思います。なぜなら、その堀はかなり浅くなってしまったからです。

チームが1日で機能的な社内ツールをプロトタイプ化できるようになれば、月額サブスクリプションを正当化するハードルはぐっと上がります。あなたが必要なのは、彼らが作れるものよりも優れていることだけではありません。AIに助けてもらいながら*彼らが作れるものよりも優れている必要があるのです。

ガートナーは2026年4月に予測しました。2028年までに、企業の半数以上が支援インテリジェンスへの支払いをやめ、ワークフローの結果にコミットするプラットフォームを好むようになるだろうと。さらに深刻なのは、2030年までに、ソフトウェア企業は、エージェント実行のために再設計するのではなく、レガシー・アプリケーションにボルトオンのAIを重ねることで、最大80％のマージン圧縮に直面するだろうと予測しています。

80％。これは四捨五入の誤差ではありません。

では、実際に生き残るのは？

Rasepiを開発していて、自分たちの価値がどこにあるのか、自分自身に正直になる必要があるからです。その答えは、どんなに優れたAIアシスタントであっても、週末のコーディング・スプリントで再現することが本当に難しい3つのことに帰結すると思います。

**誰でもテキストエディタを作ることができます。段落レベルでのコンテンツの変更を追跡し、コンテンツのハッシュ化を通じて古くなった翻訳を検出し、言語間の構造的な適応を処理する翻訳システムを構築しますか？それはアーキテクチャに焼き付けられたドメイン知識の年が必要です。AIは、あなたがより速くコードを書くのを助けることはできますが、あなたに何を構築するかを教えることはできません。

**誰かがそれを実行し、維持しなければなりません。メンテナンス？全然楽しくないマルチテナント許可システムにおけるエッジケースの処理、ブラウザの癖への対応、バージョン間のデータベース移行の管理、午前2時のCVEへのパッチ適用、Safariにのみ現れるPDFエクスポートのバグへの対応。AIは確かに初期ビルドを高速化します。しかし、Forresterの2026年4月の調査によると、ほとんどの企業はまだAIの採用を測定可能なインパクトに変えることができません。難しいのは、コードを書くことではなく、それを実行し、更新し、何年も正しく動作させ続けることだからです。構築は簡単な部分です。実際にコストがかかるのは、稼働時間、オンコール体制、漸進的な修正です。

**これは過小評価されています。自分で何かを構築する場合、セキュリティはあなた自身のものです。静止時の暗号化、監査ロギング、侵入テスト、GDPRコンプライアンス、SOC 2、そしてまだ誰も聞いたことのない次の規制は、あなたの責任です。優れたSaaSベンダーは、お客様のデータがあるべきでない場所に行き着かないようにすることだけを仕事とするチーム全体を擁しています。ほとんどの企業にとって、そのようなコストは社内で負担したくはありません。そして正直なところ、私が見てきたほとんどの社内ツールは、セキュリティ監査証跡はおろか、適切なアクセス制御さえありません。

コンポーザブル・ミドルグラウンド

興味深いのは、その答えが "構築 "でも "購入 "でもないということです。コンポーザブルなのです。SaaSツールは、難しいことをうまくこなし、優れたAPIを公開し、その周りに構築できるものを選びましょう。

これが、プラグイン・アーキテクチャーが今、非常に重要な理由です（そう、これこそが私たちがラセピのプラグイン・システムに投資してきたことなのです）。成功するSaaS製品とは、次のようなものです：「というSaaS製品です。それ以外はすべてあなたがカスタマイズしてください。これが私たちのモノリスです。

Forresterの2026年4月レポートによると、ほとんどの企業はAIの導入を測定可能なビジネスインパクトに変えるのにまだ苦労しています。高採用企業は、データとシステムを準備するためにコンサルティング・パートナーと協力する傾向が47%高い。メッセージは明確です。何を構築すべきかを知り、それをサポートするインフラを持つこと、それが実際の制約なのです。

SaaSにとっての意味

もしあなたが2026年にSaaS企業を経営しているのであれば、いくつかの不愉快な真実があると思います：

時間の節約はSaaSの古典的な売り文句でした。しかし、AIが構築時間を20～30％短縮した場合、ROIスプレッドシートの「時間節約」の数字は比例して縮小します。別のストーリーが必要です。
機能は机上の空論で、成果は製品です。彼らが気にするのは、ドキュメントの鮮度が保たれていること、翻訳が正確であること、チームが実際にツールを使用していることです。ガートナーが言う「成果重視のワークフロー」は、単なるアナリストの専門用語ではありません。それは、市場が向かっている方向です。
プラットフォームを閉鎖し、乗り換えを困難にしようとする本能は理解できます。しかしガートナーは、「記録システムを閉鎖しようとするレガシーSaaSプロバイダーは、企業がより信頼するオーケストレーション・レイヤーによってバイパスされるリスクがある」と明確に警告しています。痛い。

正直バージョン

この件に関して、私は率直に言います。ビルド対バイは決して技術的な問題ではありません。それは常に信頼についてでした。私はこのベンダーが私の問題を深く理解し、彼らのソリューションが私がこしらえたものより優れていると信じているのか？

2026年、"寄せ集め "は大幅にアップグレードされました。だから信頼のハードルも上がったのです。

私たちラズパイにとって、それは単に翻訳をサポートするドキュメントツールではいけないということです。ブロックレベルの翻訳トラッキング、コンテンツの鮮度管理、マルチテナントの複雑性など、難しい問題に深く精通していなければなりません。

これが新しいビルド対バイです。"作れるか？"ではなく、"誰かがすでに難しい部分を解決しているのに、それを作ることにエネルギーを費やすべきか？"です。

この質問は決してコストに関するものではありません。どこに注意を向けるかということです。そして、建造物が安価な世界では、注意力こそが唯一の希少資源なのです。

AIが存在するからという理由で解雇するのはやめましょう

2026-04-04T00:00:00Z

私の友人は中規模のSaaS企業でコンテンツを運営しています。昨年、彼女のチームは8人でした。ライター、編集者、ローカリゼーションのスペシャリスト、ナレッジベースを扱う人。いいチームで、しっかりした成果を出していました。その後、CEOがあるカンファレンスに出席し、AIについて熱く語って帰ってきたのですが、3カ月も経たないうちにチームは3人になってしまったのです。その理由は？AIツールを使えば、8人でやっていたことが3人でできる」。

技術的にはその通りです。残りの3人は、ほぼ同じ量を生産しています。ブログ記事、ヘルプドキュメント、製品アップデート、社内コミュニケーション。ダッシュボード上の数字は問題ありません。

しかし、私の友人はもう何ヶ月もまともに寝ていません。彼女は、ライティング、編集、プロンプトエンジニアリング、AIアウトプットのQA、翻訳管理、そしてチーム全体で共有されていた戦略的な仕事のすべてを、コンテキストを切り替えながらこなしています。残る2人の同僚も同じ状況です。そのうちの1人はすでに別の仕事を探しています。

会社は給料を5人分節約できました。また、物事の仕組みを実際に知っている3人を徐々に失っています。

正しいようで正しくない数学

ChatGPTが主流になって以来、役員室ではこのような意見が飛び交っています。もしそうなら、なぜ10人必要なのでしょうか？

それは説得力のある議論です。シンプル。クリーン。スライドにぴったり。

危険なほど不完全。

そう、AIはタスクを圧縮できるのです。Microsoftの2024 Work Trend Index](https://www.microsoft.com/en-us/worklab/work-trend-index/ai-at-work-is-here-now-comes-the-hard-part)によると、職場のAIユーザーの90%は、ツールが時間の節約に役立っていると回答しています。Microsoft Teamsのヘビーユーザーは、1カ月でCopilotを使って8時間のミーティングをまとめました。これは、会議の要約だけで丸1日を取り戻したことになります。また、85%はAIが最も重要な仕事に集中するのに役立っていると回答しています。

これは実際の数字です。生産性の向上は想像上のものではありません。

しかし、「9人をクビにしろ」という人々が決して口にしないことがあります。彼らは、認知的な負荷、文脈、意思決定、調整、品質保証、そして9人の元同僚と一緒にドアから出て行った組織的な知識のすべてを吸収するのです。

#精神的負荷は表計算ソフトではない

心理学には認知負荷理論と呼ばれる概念があります。認知負荷理論とは、ワーキングメモリで使用される精神的努力の総量を表すものです。そして、5人で分担していた思考を1人に依頼するたびに、労力を節約しているのではありません。集中させているのです。

AIは労働者の生産性を10倍にする」と言われたとき、私はこのことをよく考えます。何の生産性？より多くの言葉を生み出すこと？より多くのチケットを発送すること？より多くのスライドデッキを作成すること？しかし、知識労働の実際の難しい部分は、生産することではありません。それは考えること。何を生み出すかを決めること。文脈の理解。判断を下すこと。表面的には正しく見えても、何かが間違っていることを知ること。

AIはそれをやってくれません。AIはあなたに最初のドラフトを提供し、あなたはそれを評価するのに十分賢く、微妙なエラーをキャッチするのに十分経験豊富で、アウトプットが自信を持って間違っているときに気づくのに十分なプレゼンスが必要です。(AIが作成した社内ドキュメントを読まずに出荷する人を見たことがある人なら、私の言っている意味がよくわかるでしょう)。

[ギャラップ社の2025年版「世界のワークプレイスの現状」（https://www.gallup.com/workplace/659279/global-engagement-falls-second-time-2009.aspx）レポートによると、世界の従業員エンゲージメントは前年の23％から2024年には21％に低下。この低下により、世界経済は推定4380億ドルの生産性損失を被りました。管理職のエンゲージメントはさらに低下し、30％から27％に。女性管理職は7ポイント低下。35歳以下の管理職は5ポイント低下。

彼らはAI導入をリードするはずの人たちです。そして、彼らは燃え尽きているのです。

増幅論

この件について別の考え方を提案しましょう。

AIを持つ1人が10人分の仕事をこなせば、AIを持つ10人が100人分の仕事をこなせるということです。

もう一度読んでください。なぜなら、これはほとんど誰も話していない部分であり、すべてのCEOが夜も眠れないはずの部分だからです。恐ろしいからではなく、ほとんどの企業が捨てている莫大な機会だからです。

AIに任せられるから」という理由で従業員の半分を解雇する企業は、効率的ではありません。近視眼的なのです。競合他社が、やる気と経験のある人材で構成されるフルチームに強力なツールを与えるとどうなるかを理解している一方で、彼らは四半期ごとの人員数を最適化しているのです。

先月チューリッヒで開催されたスタートアップのイベントで、私はこのような状況を目の当たりにしました。同じ空間にある2つの会社。ほぼ同じ規模、同じ市場。A社はコンテンツチームを12人から4人に削減。B社は12人全員を残し、AIツールとトレーニングを与えました。どちらが6カ国語の多言語コンテンツを制作し、新しいフォーマットの実験を行い、ナレッジベースに毎週製品のアップデートを配信していたと思いますか？(A社ではありませんでした）。

削減すると実際に何が起こるか

10人のチームを1人か2人の「AIに強化された」スーパーワーカーに置き換えたとき、実際に何が起こるかを説明しましょう。

**1週間目は素晴らしい気分です。彼らは新しいツールを手に入れました。彼らは新しいツールを手に入れ、多くの成果を出しています。リーダーシップは感激しています。ダッシュボードの数字は、従業員数に比して信じられないようです。

**2ヶ月目、亀裂が入る。**ドキュメンテーションを担当する一人が、AIが作成したコンテンツには真剣な見直しが必要であることを発見。軽い編集ではありません。深い見直しが必要です。なぜなら、AIはあなたの製品のニュアンスや顧客の背景、先週あなたが変更した3つの事柄を知らないため、書かれていることの半分が無効になってしまうからです。レビュー作業だけで、コンテンツをより速く生成することで「節約」できた時間を食いつぶしてしまうのです。

**4ヶ月目になると、組織的な知識のギャップが現れます。彼らはただコンテンツを書いていただけではありません。彼らはプロダクトマネージャーとの関係を持っていました。彼らは長年のサポートチケットパターンから顧客のペインポイントを理解していました。彼らは、どの文書トピックが最も多くの質問を生むかを知っていました。その知識はもうありません。AIにはそれがありません。

**6ヶ月目、あなたは契約社員を雇っています。しかし、請負業者もコンテキストを持っていないので、より悪い結果に対してより高い時給を支払うことになります。

これは作り話ではありません。私は昨年だけでも3つの会社でこのパターンが繰り返されるのを見てきました。

データによれば、人材を確保し（そして育成し）なさいということです。

World Economic Forum's Future of Jobs Report 2025](https://www.weforum.org/publications/the-future-of-jobs-report-2025/digest/)は、世界の1,000社以上の雇用主に労働力計画について質問しました。この数字は興味深い物語を物語っています。はい、40％の雇用主は、AIが作業を自動化する場合、人員を削減する予定です。しかし、85％は既存の従業員のスキルアップを計画しています。また、70%は人員削減ではなく、新しいスキルを持つ人材の雇用を見込んでいます。

報告書では、2030年までに7800万人の雇用が純増すると予測しています。これは、9,200万人の離職者を考慮した後の数字です。世界は労働者の減少に向かっているのではありません。異なるスキルを持つ労働者が増えているのです。

そして、「従業員数を削減しよう」と考えているすべてのCEOが頭を悩ませるのがこれです：64％の雇用主が、従業員の健康と福祉をサポートすることを、人材確保のための重要な戦略として挙げています。コスト削減」ではありません。"すべてを自動化する "のでもなく**なぜなら、従業員を使い捨てにする企業は、優秀な人材を後から雇うことができないからです。

一方、BCGとハーバード・ビジネス・スクールの研究によると、チームがクリエイティブなタスクにAIを使用した場合、約90%がパフォーマンスを向上させ、アウトプットの質はコントロールグループよりも40%上昇したとのこと。しかし、この研究では、すべてのリーダーを不安にさせるようなことも発見されました：AIが支援したグループのアイデアの多様性が41％低下したのです。

これが何を意味するか考えてみてください。あなたは10人のチームから7人を解雇しました。残った3人はAIを使って同じ量を生産します。しかし、アイデア、視点、アプローチの幅は半分近くに縮小します。生産性は高いように見えますが、徐々に均質化していきます。そして、競合他社が純粋にクリエイティブなものを出荷し、なぜあなたのチームが同じことをしないのかがわからなくなるまで、誰も気づかないのです。

誰も予算をつけない精神的負荷

マイクロソフトの調査によると、68％の人が仕事のペースと量に苦しみ、46％の人が燃え尽きたと感じています。そしてこれは、あなたが彼らに、かつての3人のチームメイトの仕事をするようになったと言う前の状態なのです。

生産性ダッシュボードには表示されないもの、それは最後の防衛線であることの認知コストです。AIのアウトプットをレビューする唯一の人間である場合、オフの日はありません。ナレッジベースの唯一の所有者である場合、すべてのサポート質問があなたのデスクに届きます。チームが「適正規模」であるため、アイデアを出し合う相手が誰もいない場合、すべての決定はあなた一人のものとなります。

私がRasepiを構築してきた理由の一つは、この問題を間近で見てきたからです。ドキュメント作成チームが縮小しても、知識は一緒に縮小しません。言語を超えて存在し、最新であり続け、正確でなければならないコンテンツの量は、それを管理する人が少なくなったからといって減るわけではありません。むしろ、増えてしまうのです（ちなみに、この問題を解決するために、私たちはRasepiを開発しています。強制的な有効期限やブロックレベルの翻訳のような機能によって、小規模なチームが圧倒されるのではなく、純粋に効果的になります）。

しかし、どんなに優れたツールでも、根本的に壊れた人材配置の決定を解決することはできません。人間の判断、文脈、配慮の必要性を自動化することはできません。人間がより効果的に働けるようにするだけです。

賢い企業が実際に行っていること

マイクロソフトのデータで最も印象的なのは、「AIパワーユーザー」の姿です。1日に何度もAIを使い、30分以上節約している人たちです。彼らは、AIのさまざまな使い方を試す傾向が68％も高いのです。彼らは単にアウトプットを増やすだけではありません。仕事の進め方を再設計するのです。

さらに、AIに投資している組織にはAIが存在するということです。AIパワーユーザーは、仕事におけるAIの重要性についてCEOから話を聞く可能性が61％高い。また、リーダーシップから自分の職務全体を見直すよう奨励される可能性が53％高くなります。ChatGPTにログインするだけでなく、カスタマイズされたトレーニングを受けることができます。

つまり、最も生産性の高いAIワーカーは、レイオフの生き残りではありません。彼らはサポートされ、投資されたチームのメンバーなのです。

私が「人員削減」路線をとった企業で目にしたことと対比させてみましょう。残った社員はパワーユーザーではありません。彼らは、必死に物事を動かそうとする圧倒されたジェネラリストです。生き残るためにAIを使うのに忙しく、AIを試す時間もありません。機能を見直すこともなく、ただ...彼らだけが、すべてをこなしているのですから。

誰も言及しない知識問題

もう一つあります。誰もそれについて話しているのを聞きません。

経験豊富な知識労働者を解雇すると、知識は彼らとともに去ります。知識はビルには残りません。ウィキにも残りません。AIにもありません。プロセスを構築し、エッジケースを理解し、どの顧客がどの詳細を気にしているかを知っていた人々の頭の中にあるのです。

優れたAIツールがありながら、組織的な知識がないとどうなるかわかりますか？美しくフォーマットされ、自信たっぷりに配信された、まったく間違った情報が得られるのです。規模が大きくなれば。

先月、あるフィンテック企業の文書責任者と話をしました（彼女は名前を伏せたのですが、それが何かを物語っています）。チームが6人から2人に削減された後、開発者向けドキュメントのメンテナンスにAIを多用するようになったそうです。4ヶ月以内に、彼らはサポートチケットが急増していることに気づきました。ドキュメントには問題がないように見えました。よく書かれており、表面上は最新でした。しかし、そこには製品に関する深い知識を持つ人だけが気づくような微妙な誤りが含まれていたのです。技術的には正しいが、実質的には誤解を招くようなAPIパラメータの説明。旧チームの誰もが知っているステップを見落とした移行ガイド。AIが知ることのできない些細なこと。なぜならAIはスタンドアップに参加するわけでもなく、Slackのスレッドを読むわけでもなく、コーヒーメーカーにいるサポートエンジニアから「ああ、あのドキュメント、また間違ってるよ」と苛立つ声を聞くわけでもないからです。

本当の質問

では、実際に会話すべきことは何だと思いますか？

そうではなくAIを導入した今、何人を削減できるか？

しかしすでにいる全員にAIを与えたら何が可能になるか？

AIツールを導入した10人のドキュメンテーション・チームが冗長になることはありません。2カ国語ではなく12カ国語でコンテンツを管理できるチームになるのです。自動化された鮮度チェックによって、すべてのコンテンツを最新の状態に保つことができます。新しいフォーマットを試したり、ヘルプコンテンツのA/Bテストを実施したり、インタラクティブなガイドを作成したりすることができます。

AIを導入した10人のマーケティングチームは、同じ仕事をする5人のストレスが増えるだけではありません。以前は不可能だった規模のキャンペーンをパーソナライズし、よりクリエイティブなバリエーションをテストし、市場の変化に迅速に対応し、AIが決して生み出さないような純粋に独創的なアイデアを思いつく認知的な帯域幅を持つことができる10人になるのです。

これはコストではありません。これは投資であり、その見返りは複利的なものです。

##この結末

次の5年を勝ち抜く企業は、最も多くの首を切った企業ではありません。既存のチームを純粋に有能にする方法を発見した企業でしょう。

問題は、1人で10人分の仕事ができるかどうかではありません。問題は、10人全員が100人分の仕事をこなせるようになったらどうなるか、ということです。

もしあなたがこれを読んでいるリーダーなら、ひとつお願いしたいことがあります。次の「AIを活用したリストラ」を承認する前に、前回のリストラの後に残った人たちと話をしてください。彼らがどうしているか聞いてください。時間がなくてやめてしまったことを聞いてください。隙間からこぼれ落ちているものを聞いてください。

そして、もし彼らが一人で負担を背負うのではなく、充実したチームと最高のツールを手に入れたら、何を達成できるかを想像してください。

それは空想ではありません。従業員を入れ替える代わりに、従業員に投資する意思のある企業にとっては、それが次の12カ月間の課題なのです。

読者とライターは異なるメンタルモードにあります。なぜどのツールも同じ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 で文書化されています。

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

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 →

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

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__

プラグインは/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.**ブロックの翻訳がチェックされます。

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

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

TCDEV Blog

LLMは英語で考えましょう

研究は声高にこう言い始めています

同じ場所でRAGが壊れる理由

これは反ローカリゼーションではありません

私が今最も信頼しているアーキテクチャ

これがラセピにとって意味すること

クロード・デザインと一人クリエイティブ・エージェンシー

クロード・デザインが実際に行っていること

すべてを変えるスタック

2ヶ月前ならこのために何を捧げたか

ツールを追加するだけ」の倍率

ドキュメンテーション製品にとっての意味

変に高くつくところ

正直な注意点

1つのAPIキー、多数のテナント：顧客間でDeepL翻訳を分離する方法

問題：DeepLはあなたの顧客について知らない

データベースは真実のソースです。

スタイル・ルール: 同じパターン、異なる API

翻訳呼び出し: すべては

ブロックレベルのキャッシュ: 翻訳メモリとしてのデータベース

テナントごとに別のキーを使用しませんか?

実際にあなたを守るもの

トークン バーニングは新しいコード行数です。

We've been here before

同じ過ち、異なるユニット

評価基準が目標になるとき

この問題のドキュメント版

代わりに何を追跡すべきか

AI の分断がチームを真っ二つに

ギャップは測定可能

2つのスピード、1つのチーム

誰も語らない競争優位性

これはテクノロジーの問題に見せかけた、人の問題です。

この先

ビルドとバイの再考：2026年の実際の意味

古い枠組みは死んだ

新しい微積分

では、実際に生き残るのは？

コンポーザブル・ミドルグラウンド

SaaSにとっての意味

正直バージョン

AIが存在するからという理由で解雇するのはやめましょう

正しいようで正しくない数学

増幅論

削減すると実際に何が起こるか

データによれば、人材を確保し（そして育成し）なさいということです。

誰も予算をつけない精神的負荷

賢い企業が実際に行っていること

誰も言及しない知識問題

本当の質問

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

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

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

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

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

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

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

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

書き手の環境

読み手の環境

AIの表面

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

見た目以上に重要な理由

読者の信頼

ライターの生産性

AIの信頼性

メンタルモデルの転換

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

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

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

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

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

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

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

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

コアシフト

誰も計画しなかった旅

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

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

トークンバーニングは新しいコード行数です。