コンセプト

作業はAIへ。創造は人へ。

価値は、人がより創造的な仕事に向き合えること

産業マニュアル制作の現場では、扱う情報は増え続け、求められる精度や対応範囲も年々広がっています。だからこそ、人の力を注ぐべき場所を、あらためてはっきりさせたい。AIに任せられる作業はAIに任せ、そこで浮いた時間と労力を、人にしかできない創造的な仕事――何を伝えるか、何が正しいか、何を資産として残すかという判断に向けられるようにする。WikiWorks Ver.5.0は、その価値を実現するために作られています。

WikiWorks Ver.5.0の5つの柱

1

AI活用を前提とした設計

AI・人・コンテンツを、一つの基盤でつなぐ

「書く」から「組み立てる」へ。AIが担うこと(下書きの生成、品質の点検、情報収集と提案)と、人が担うこと(何を伝えるかの設計、正しさの判断、資産化)を分け、一つの基盤でつなぎます。何を、どこに、どう書くかという編集の判断は、AIの時代でも価値が下がらない――むしろAIが正しく働くための前提条件です。
2

コンテンツ資産を新たな価値へ

散在する情報から、つながる知識資産を形成

既存の情報資産を取り込み、AI・マップ・トピックの構造でつながった知識として扱えるようにします。形式も置き場所もばらばらな情報を、MCPやAPIで外部と接続し、開発・営業・マーケティングなど様々な部門がAIを通じて活用できる仕組みを提供する予定です。これまでの資産を捨てずに活かせます。
3

トピックを最小単位に、文書を構造化する

部品(トピック)単位の情報管理

部品(トピック)と骨格(マップ)で文書を組み立てます。同じ部品を複数の文書から参照でき、1か所の更新がすべての参照先に反映され、改訂の取り残しも相関ビューで把握できます。AIは部品を1つのまとまりとして読むため、文脈を保ったまま理解できます。書き慣れた文書の形で書き始め、AIの支援でトピックへ再構成していく機能も開発中です。
4

持続可能な基盤

AIの進化に対応できる柔軟性

特定の製品やフレームワークの事情に左右されず、10年先も使い続けられる設計です。見出し・本文・属性を意味ごとに区別した構造でデータを保存するため、AIが内容を正しく読み取れます。独自開発の接続の仕組み(MCP)で社内システムやOffice文書の情報資産と連携し、現行WikiWorksの機能・データもそのまま引き継げます。
5

柔軟な拡張性

最小限のコアと、選べるモジュール

必要な機能を、必要なときに追加できる構成です。トピックとマップの管理、バージョン管理、権限とワークフローは基本機能(コア)としてどのエディションにも共通。そこにAIモジュール(執筆アシスタント、レギュレーションチェックなど)や連携・出力モジュール(MCP連携、DTP連携、翻訳品質チェック、DITA・S1000D対応など)を選んで追加でき、小さく始めて広げていけます。

なぜ、つくろうとしたか

01 / 09

もっと力を注げるように。

2005年、編集プロダクションとして出版・マニュアル制作の現場に携わってきました。多くのクライアントのマニュアル制作を通じて、そこで生まれた旧WikiWorksにも、使いやすさとカスタマイズ性の限界が少しずつ見えてきました。制作にかかる時間とコストを減らし、企業が製品価値を高める仕事にもっと力を注げるようにしたい――だったらゼロから作り直したい、というのが最初の一歩でした。

02 / 09

データと機能を、分けて設計する。

一次データは、将来どんな用途にも変換しやすい、フォーマルな形式にしたい。共通の土台は小さく保ち、その周りにアドオンで機能を積み上げていく。作業はAIへ、創造は人へ――全部は任せず、必要な場面だけで使う。特定の外部基盤に依存しすぎて、後で身動きが取れなくなることは避けたい。この距離感を最初から大切にしたいと考えました。

03 / 09

書くのは、エンジニアだけじゃない。

データを資産にするなら、作れる人が「情報設計者」に限られていては積み上がりません。本当に価値のある知識を持っているのは、コードが書けるエンジニアではなく、現場の専門知識を持つ書き手です。技術の壁なしにそのまま使えるように、UIを含めその壁を最初から取り除きたいと思いました。

04 / 09

小さな現場にも届く仕組みに。

月額課金でコストを分け合うホスティング型も、セキュリティ要件の厳しい企業向けの専有型も、どちらも選べる設計に。ドキュメントの数が少ないクライアントにも、導入する価値を出したい。

05 / 09

ページではなく、トピックへ。

一番の分岐点は、ページではなくトピックへの転換でした。一般的なCMSはページ単位ゆえ、同じ内容のコピペや更新漏れが方々で起きてしまいます。AIに読ませるにも、ページという単位は粒度が大きすぎる。段落、そして「トピック」への到達を目指したのは、再利用だけでなく、AIも人と同じ単位で読めるようにしたかったからです。

06 / 09

誰もが、安心して使い続けられるツールへ。

トピックを中心に、バージョンと翻訳、そしてドキュメント全体をどう繋げるかを考えました。勝手に書き換わらない安心感と、更新があったときに気づける仕組み。保存と公開を分け、書き手が気兼ねなく保存できるようにしたい。

07 / 09

増えるほど、引き算する。

開発すればするほど、機能は増え、UIはどうしても複雑になっていきます。機能を作るたびに、表に出すもの・隠すものを見直し、判断や行動に効かない情報を削っていく。迷わず、見た通りの挙動で、シンプルで考えなくても使えることを目標にしました。

08 / 09

パッと使えるように。

旧WikiWorksをお使いのお客様にも、他社のマニュアルやドキュメントをお持ちのお客様にも、ゼロから作り直す負担がないように。外部データをAIがRAG検索で読み解き、章立てに沿ってトピックの下書きを自動生成できるようにしたい。生成された内容は必ずドラフトとして着地させ、採用するかどうかは人が判断できるようにしたい。

09 / 09

ひとりの仕事を、チームの仕事に。

複数の書き手が同じトピックに関わるようになるほど、誰が何を編集し、どこで再利用されているかが見えにくくなっていきます。相関ビューで、参照の関係・改訂の影響範囲・執筆の分布まで、つながりから把握できるように。ひとりで抱え込む作業ではなく、チームとして進めている実感を持てるようにしたい。