本ブログはLinuxOS上でWordPressを配置して運用しています。
ブログ・サーバーのOSやWordPressのバージョンが古く、2026年10月22日に公開された「JVNVU#99905564：PHPにおける複数の任意のコードが実行可能な脆弱性（CVE-2026-109618、CVE-2026-109619）」が該当するため、10月22日に社外からのアクセスを停止する措置が取られました。
当該脆弱性対策を行ったうえで、この間、2026年11月6日に社外からのアクセスを再開しました。脆弱性対策のため、WordPressを最新にアップデートするなどの措置を行ったため、表示レイアウトやサイドメニューが大幅に変更になっています。
従来よりブログをご覧いただいていた皆様には、ご不便をおかけしてしまうかもしれませんが、なにとぞご容赦いただきたくお願い申し上げます。
アンテナハウス株式会社は、来る2026年11月4日（水）～6日（金）に開催される「DX 総合EXPO 2026 秋 東京」に出展致します。
今回のDX 総合EXPOではPDFの作成から編集・加工ができるツール並びに電子署名・電帳法関連商品を紹介いたします。サーバーのシステムに組み込んで一括処理ができるライブラリから単独のPCで使用するアプリケーションまで、PDFや電子署名にまつわるお悩みを解決する製品群をご提案いたします。
→ https://expo.bizcrew.jp/event/16157/module/booth/432823/449920
DX 総合EXPO会場への入場には来場登録（無料）が必要です。来場登録をして頂ければ、ブース個別の訪問予約を行うことができます。来場登録時にプロモーションコードを入力してから訪問予約の上、当日弊社ブースにご来場いただきますと、会期終了後に事務局からAmazonギフトカード1,500円分が進呈されます。弊社ブースへのご来訪際は是非事前予約をご活用ください。
→ https://expo.bizcrew.jp/event/16157/module/booth/432836/477367
皆様のご来場を心よりお待ちしております。
内容としては、Formatterのマニュアルに検索を実装した話題*から続きます。
検索機能の実装は「今、検索機能を用意するということ」について改めて考える機会となりました。
社の見解ではなく個人の見解となりますので、ご承知おきください。
検索機能は実装の必要があるのか
「資料はAIに読ませればよいので、検索機能をサイトに載せる意味はあるのか」という問いを立ててみます。
実際、
今回実装に際し資料を用意したときも「このURLの文書を参照して」とか、「必要な情報を別文書に書き出して」といった指示を挟んだりしています。
「指定された文書を読み込んで、必要と思われる事項を選別する」という機能は、
多くのコーディングエージェントに用意されているようです。
とはいえ、その「必要な箇所」の選別に大量の文書をそのまま読ませるというのは、コストとパフォーマンスの両面であまり望ましくありません。
コストの面では分かりやすく、AIクラウドサービスでは読ませた量や書かせた量、すなわちトークン消費を単位とした従量課金や使用量のリミットという縛りが固定化しつつあります。
フロンティア、より精度の高い思考ができるとされる上位のモデルはトークンあたりの価格もより高く設定されています。
パフォーマンスの面では、比較的長い記憶を扱えるようになったといっても、1から100まで資料を読ませているのでは記憶容量は早く枯渇します。
作業を重ねるうちに読ませた資料が適切に反映されなくなってくるといった話題もかなり浸透してきましたね。
よって、そのような選別をより安いコストで行う手段があればそれに越したことはありません。
とはいえ、この点ではAI用の検索手段を各々が用意すればよいといえます。
製品側が提供する検索
では、製品側が検索機能を提供することでどのような価値があるのか。
端的には「結果を保証する」ことにあります。
これはマニュアルを提供すること自体にもいえます。
AIであれ人間であれ、自前の検索機能を用意した上で
ある検索の結果が0件であったとき、
「検索した内容は文書内に存在しない」と判断を下すことになるでしょう。
実際には文書内に存在するのに、
検索によって「この機能がないようなので、この製品は使えない」と判断が下されるのは損失です。
この話を広げるとベクトル検索の提供などにまで話題が広がりますが、
少なくとも「明確に文書内に存在する」事柄の検索については、公式のマニュアルとして提供する意義があるといえます。
逆に「存在しない機能を公式の検索が提供する」というのはかなりよろしくないため、
LLMブーム初期のRAGや自動応答チャットインタフェースが試みで終わってしまう事例が多くあったのもむべなるかな。
まとめ 大量の文書は読み切れない
LLM以前、2010年代には既に情報爆発、情報氾濫の時代と言われていました。
これは主にインターネット上の情報を指してのものでした。
現在はAIによって、ここにローカル、自分のPC内の情報もまた読み切れない量で増加しつつあります。
AIに自動で作業を進めさせると、もはや人間がチェックできないスピードと量でコードが生成されていきます。
「必要なときに、必要な情報を読ませる」という点において、DITAのようなトピック単位で情報完結するようなアーキテクチャは依然有効、むしろより重要になりつつあります。
AI時代の新しい形式として耳目を集めたGoogleのOpen Knowledge Format(OKF)なども、
メタデータや簡易的な説明、内容の単位、参照の記述、配置の構成など収斂進化や再発明ともいうべき構造を持ちます。
言い換えれば、
AIが読むにしろ人間が読むにしろ「必要な情報か端的に判断できる機構があること」「必要な情報がまとまっていること」「処理しやすい形で記述されていること」が大事であるということです。
今回検索機能を実装するにあたっても「文書がこういう構造だったらなあ」と思うことが何度もありました。その詳細はまた別の記事に譲りたいと思います。
Antenna House Formatter V7.5 改訂6版が本日リリースされました。
改訂内容については下記URLをご確認ください。
改訂情報 – Antenna House Formatter V7.5 https://www.antenna.co.jp/support/update-sys/ahf/ahf75.html#MR6
今回、製品改訂とは別に更新がありました。
日本語版のオンラインマニュアルに検索機能が追加されています。
Antenna House Formatter V7.5 – マニュアル https://www.antenna.co.jp/AHF/help/ja/
マニュアルへの検索機能の付加は、
以前から要望が上がっていたものの、社内リソースの関係で優先順位が下げられていた過去があります。
今回、社内でのAIによるコーディングによる課題解決の検証として、課題にこの検索機能の実現を選択しました。
ベクトル検索やAI検索を実装した訳ではなく、
キーワード検索用データのビルドと検索フォームの組み込み用のアプリケーションを、
AIへの指示をメインに実装したという話題です。
コーディングでの試行錯誤については別記事に分けての掲載を予定しています。
右下に検索用のランチャーが配置されるようになりました。
検索ランチャーの待機状態
クリックして検索フォームを展開、キーワードを入力して検索ボタンを押すと検索実行
検索フォームに入力して［検索］ボタンのクリックでマニュアルの内容が検索され、ダイアログが前面に表示されます。
検索結果がダイアログで表示される
入力についてのポイントは下記の点です。
-キーワードのように先頭に-を入れると除外キーワードになります"キーワード"の形でスペースや除外に使用する-文字を含む"-d"のようなテキストも検索できます脚注で検索するとfootnoteの検索結果も表示されます［検索のヘルプ］をマウスホバーすると同様の内容が表示されます。
［閉じる］ボタンまたはダイアログ外の暗い領域をクリックするとダイアログが閉じます。
このとき、フォームに入力された内容は、現在のページ内でハイライトも行われます。検索結果のページに移動した場合も、ページ内でそのキーワードがハイライトされます。
検索結果のページでキーワードがハイライトされている
検索結果は登場箇所のページと見出しのパンくずリストと登場箇所のテキストがリスト表示されます。（リンクがあるのは文書と、対応するIDのある見出しのみです。）
検索結果での見出しのパンくずリスト表示
クライアントで完結しており、検索内容はサーバに送られたりはしません。
UIや機能について、今後変更が行われる可能性があります。
オンライン版の先行という形であり、製品に同梱されるマニュアルには現在は搭載されていません。
SNSやメールなどでフィードバックいただければさいわいです。
Microsoftの開発プラットフォームである .NETのうち、.NET 8と.NET 9のサポートが2026年11月10日で終了となります。
サポート終了の時点では、.NET 10が唯一のLTS（Long Term Support）対象のバージョンとなります。このため、サポートが終了する.NETバージョンを使用しているユーザーのシステム部門やシステムインテグレータでは、.NET 10への移行が課題になっているようです。
ご参考のため、当社システム製品の.NET 10対応を次のページに整理しました。
アンテナハウスシステム製品の.NET 10動作確認状況
この表は、各製品の.NETインターフェイスが、.NET 10環境で動作するかどうか、という確認を行った結果をまとめたものです。留意点としては、各製品の.NETインターフェイス自体を.NET 10 SDKでビルドしたわけでなく、また、.NET 10向けにビルドしたわけでもありません。
アンテナハウスシステム製品の本体は、一部の製品を除いてC++で開発されています。そして、各製品の.NETインターフェイスは、システム製品がもつC++のAPIを.NETプログラムから呼び出す、いわばパラメータの対応付けをする役割のみを担っている存在です。
従って、システム製品の.NETインターフェイスとして提供されているオブジェクトは、動作環境となる.NETのバージョンにはほとんど依存していません。
例として Antenna House Formatter では「XfoDotNetStdCtl75.dll」が該当します。その、機能は次のWebページで説明されています。
Antenna House Formatter V7.5 .NET インターフェイス
こうしたことから、古い.NET向けにビルドされているオブジェクトを使用することによるセキュリティの問題も発生しないと考えております。
『PDF Tool API』活用術その２．『Cursor』を用いたコーディングの補足説明です。
『Cursor』とは何か
Cursorは、Microsoftの「VS Code（Visual Studio Code）」をベースにして作られた、AIを使ってプログラム（コード）を書くための専用エディタです。開発したのは2022年に設立されたAnysphere社（米国・カリフォルニア州）です。
VS Codeの操作性、設定、拡張機能を引き継ぎながら、最先端のAI機能を使ってプログラムを書くことができます。VS Codeは既にデファクトのコードエディタとして普及しているので、VS Codeを使い慣れたユーザーは、新たな操作を学ばなくてもすぐに使い始めることができるというメリットがあります。
GitHub Copilotのような、既存のAIとエディタの組み合わせは「エディタにAIの窓口を後付けした」のに対して、Cursorは「AIがコードを書く前提で再設計されたエディタ」にあたります。単に一つのファイルを編集するだけではなく、大きなプログラムのプロジェクト全体のディレクトリ構造や関連ファイルをAIが、自動で読み込み、プロジェクト全体の文脈に合わせた提案をするようになっているのが特徴です。
Cursorの使用料金体系
Cursorの料金体系はかなり複雑です。以下は、2026年8月28日時点の概要です。
まず、契約方式が月額か年額かがあります。次に使用できる機能によって、ホビー、個人（Pro、Pro Plus、Ultra）、チーム（Standard、Premium）、企業カスタムのグレードに分かれています。ホビーは使える機能が最少、企業カスタムは最多です。例えば、個人のPro料金は月額20ドルとなります。
契約金額に応じて月あたりに使用可能なトークンが割当られます（クレジットトークン）。AIモデルにリクエストを送信して、結果を受け取るとクレジットトークンを消費することになります。
消費するトークンの計算方法は、Cursorのモデルと料金にあり、計算式は次のようになっています。
消費額=(入力トークン数×入力単価)+(出力トークン数×出力単価)+(キャッシュ読み取りトークン数×キャッシュ単価)＋（キャッシュ書き込みトークン数×キャッシュ単価)
「Cursorのモデルと料金」では入力／出力／キャッシュ読み書きの単価は、100万トークンあたりのドルで示されていますが、選択するAIモデルによってかなり異なります。
月単位で割り当てられたクレジットトークンをすべて消費してしまうと、上位のグレードにアップするか、追加の料金を払うことになります。
AIモデルと料金
使用するAIモデルはユーザーが選択できます。大きくCursorモデルと、サードパーティモデルに分かれており、Cursorモデルには、Cursor Grok 4.6、Grok 4.5、Composer 2.5が含まれます。サードパーティモデルは、Anthropic、OpenAI、Googleなどの主要モデルから選択できます。
Cursorモデルの単価でみると、Composer 2.5が一番安く設定されています。これはCursor社が開発したAIモデルのようです。
サードパーティのモデルは高いものから安いものまで幅が広くなっています。総じて、入力、キャッシュ読み書きと比べると、出力料金が一番高く設定されています。
参考のため、AIモデルの出力料金の平均値を比較してみると、AnthropicのClaude系（但し、Claude Opus 4.7 (fast mode)が異常に高いので平均の計算では除外）13モデル平均が21ドル、OpenAIのGPT系17モデルの平均が11ドル強、GoogleのGemini系8モデルの平均が8ドルとなっています。
各社で随分と差がありますが、これはAIモデルの性能によるのか、人気なのか、それとも提供元の価格に対する考え方の相違なのか？ 興味はありますが、分かりません。
いずれにしても、このように複雑な料金体系になると安いのか高いのか、なかなか判断が付きにくいところです。使ってみて実績情報を収集して判断するしかないかもしれません。
補足
SpaceXは、2026年6月16日に、Cursorを買収すると発表した（2026年7〜9月期にカーソル買収を完了の予定）。さらに、8月29日のニュースによるとOpen AIは、11月中旬以降、Cursorへの技術提供をやめるようです。
前回
新連載：AIを利用するソリューション作成（5）Wordで編集した文書をWordPressでパブリッシュするソリューション
新連載：AIを利用するソリューション作成（3）AIを使って製品開発のアイデアを詰めるで、ソリューションのアイデア検討をGeminiを使って行い、コーディング用AIとしてCursorを使用する開発のことを紹介しました。
AIに相談して企画を考え、AIに開発させた、本ソリューションの概要を、次のWebページで紹介致しています。さすがに、Webページは人間が制作したものですが・・・
活用例：REST API1を使ってWordPressへ自動ポスト
WordPressにWord（docx）文書を取り込むには、ここで紹介したREST APIを使う方法（以下、アンテナハウス方式）以外に、「Mammoth .docx converter」というプラグインを使う方法があります。
アンテナハウス方式とMammoth .docx converterの違いをGeminiにまとめさせました。（但し、Geminiの回答には、妥当と思えない推測や誤りが含まれていたので、可能な範囲で不適切な箇所を修正しています。）
① 「1冊のマニュアル（複数ページ）」か「1本のブログ記事」か
•アンテナハウス方式はマニュアル特化: 数百ページある1冊のWordマニュアルを「Docx to HTML」で章や節ごとにHTMLファイルへ自動分割し、それをPython等のスクリプトがWordPressへ一括登録します。同時に「親・子・孫」の階層や並び順（menu_order）まで組み上げ、「1冊の本をまるごとWebサイト化」します。
•Mammoth方式は単発記事型: WordPressの投稿画面にあるボタンからWordファイルを選び、その記事の本文欄にHTMLとして展開します。あくまで「Wordで書いた原稿をエディタにコピペする代わり」の機能です。1つのWordファイルを複数ページに分割して階層構造を作るものではありません。
② 「完全自動化（パイプライン）」か「手作業」か
•アンテナハウス方式: 手元のWordが更新されたら、コマンド一発でWordPress側へ自動デプロイ（上書き同期）できます。WordPressの管理画面にログインしてポチポチ作業する必要がありません。
•Mammoth方式: 記事を更新するたびに、WordPressの管理画面にログインし、対象の記事を開き、ファイルを選び直して「挿入」ボタンを押し、下書きを保存・公開するという手作業が発生します。
提案時の使い分け・棲み分け
クライアントから「Mammothのような無料プラグインで取り込むのと何が違うの？」と聞かれた際は、以下のように説明すると非常に明快です。
「Mammothプラグイン」は、ブログライターがWordで書いた1本の記事をWordPressにコピペする手間を省くための補助ツールです。
対して「アンテナハウス＋REST APIソリューション」は、Wordで書かれた分厚い1冊のマニュアルを、章立てや目次、URL階層を維持したまま、ボタン一つでWeb取扱説明書サイトとして丸ごと構築・自動更新するための『出版・運用システム』です。
単発のオウンドメディア記事ならMammothで十分ですが、「目次付きの体系的なWebマニュアル」を継続的に運用・改訂していく用途においては、Docx to HTML＋REST APIの自動化方式が便利でしょう。
企画、開発だけではなく、宣伝もAIで行うということになると人間の出番がかなり減りそうです。しかし、誤りが多いので100％AI任せにもできません。
本ソリューションを8月27日CDシンポジウムで紹介致します。
『マニュアルは、Wordで書いて、WPで配る』セッション時間 8月27日（水）14:30-15:30（26-SP11 アンテナハウス(株)）
前回
新連載：AIを利用するソリューション作成（4）自然言語処理のローカルAIを使い、PDFから名前を捜して墨消し
次回
新連載：AIを利用するソリューション作成（6）『Cursor』を用いたコーディング
7月17日に公開した『PDF Tool API』活用術その１．BERTを組み合わせた名前墨消しについて、入門者向けに解説を補足します。
このページでは、アンテナハウスの「PDF Tool API」の機能の一つである、PDFの墨消しのプログラムにAIを利用する例を紹介しています。
通常の墨消しでは対象となる名前を予め用意します。これに対し、本ページで紹介している応用例の特徴は、墨消しの対象となる名前の候補を、墨消し対象PDFから抽出したテキストの中から、AIを使って自動的に抽出することにあります。
テキストの中から名前を認識するのに使用しているのが、「jurabi/bert-ner-japanese」という長い名前のAIです。この名前は本AIモデルがオープンソースとして公開されている保管場所（Hugging Face）における識別名にあたります。次の単語を組み合わせたものです。
jurabi：このAIモデルを作成・公開した開発者のアカウント名（会社名）
bert：モデルの仕組み
ner：固有表現抽出
japanese：日本語対応
次に専門用語を簡単に説明します。
BERTはGoogleが開発した自然言語処理AIで、テキストの解析・分類を行うモデル（判別型）です。GoogleのGeminiのような生成AI（文章をつくり出す）モデル（生成型）とは別のジャンルになります。
NER（固有表現抽出）は、文章の中から人名、地名など特定カテゴリの固有キーワードを自動で検出・抽出することを意味します。
jurabi/bert-ner-japaneseは、東北大学の乾研究室（現：東北大学 自然言語処理グループ）が、Hugging Faceで公開した、cl-tohoku/bert-base-japanese-v2をチューニングしたものです。東北大学が公開しているのは、Wikipedia（日本語）のテキスト全文をもちいて事前学習したモデルで、そのままでは特定のタスクに使えません。jurabi/bert-ner-japaneseは追加学習により、入力された文章から以下の8種類の固有表現を自動で特定・タグ付けできます。
・人名
・法人名（企業、団体など）
・政治的組織名（政府機関、政党、国際機関など）
・その他の組織名（スポーツチーム、劇団など）
・地名
・施設名（建物、駅、空港など）
・製品名（商品名、書籍、映画、ブランド名など）
・イベント名（祭り、会議、スポーツ大会など
判別型モデルの主な用途はデータの分類・見分けです。生成型モデルと比較して、計算に要するコストが比較的小さく、軽量・高速です。そこで、手元のPCで動かすことができます。
クラウド上の大規模データセンターで動かす必要がないので、機密情報を外部に出したくないといったセキュリティ上の制限がある場合でも適用できる、といった特徴があります。
外部に漏洩してはこまる機密情報を墨消ししたいので、クラウド上の大規模データセンターではなく、手元のPCで処理できるAIモデルを使っています。
なお、「『PDF Tool API』活用術その１．BERTを組み合わせた名前墨消し」で紹介しているサンプル・プログラムの作成には Microsoft Copilot を使用しています。
次回：新連載：AIを利用するソリューション作成（5）Wordで編集した文書をWordPressでパブリッシュするソリューション
前回：新連載：AIを利用するソリューション作成（3）AIを使って製品開発のアイデアを詰める
去る2026年7月22日（水）から24日（金）まで開催された『DX総合EXPO2026夏東京』では、多くの皆様に弊社ブースへお立ち寄りいただき、誠にありがとうございました。猛暑が続く中、最終日には雨の予報もあるあいにくの天候でしたが、多くのお客様にご来場いただき、製品・サービスに関するご質問やご相談を数多くいただきました。心より御礼申し上げます。
ご相談いただいた内容のうち、会場で回答できなかったご質問につきましては、担当者より改めて個別にご連絡いたします。今しばらくお待ちいただけますと幸いです。
当日来場できなかった方でも、展示会でご紹介した製品・サービスについて詳しく知りたい方や、デモ・個別相談をご希望の方は、ぜひお気軽にお問い合わせください。担当者が対応させていただきます。
今後も展示会やイベントへの出展を予定しておりますので、もしご都合が合いましたら是非お立ち寄りください。
今後のイベント開催情報や展示会出展情報につきましては、弊社Webページのトップ「イベント・セミナー」欄に掲載いたしますので、折に触れてご確認を頂けますと幸いです。
改めまして、ご来場いただいた皆様に心より御礼申し上げます。
引き続きアンテナハウス株式会社をよろしくお願いいたします。
前回 AIを利用するソリューション作成（2） 目的としてのAIと手段としてのAIで説明したように、生成AIのプロンプトに質問を投げると、どんなことでも知っているかのように回答してくれます。質問が支離滅裂でも、単語や画像を一つを投げるような質問になっていないときも、その中のキーワードに反応して回答を生成しているようです。
また、特にGeminiは、かならず前向きな回答をくれます。こういう特性を鑑みると、AIにアイデア出しをさせたり、あるいは企画のアイデアをAIを相手に詰めたり、ブレーンストーミングの相手にするのが有効でしょう。
具体的な例を紹介します。当社では、自社製品『Docx to HTML』を応用して、Microsoft Wordで編集したマニュアルでHTMLに変換し、WordPressで公開するソリューションのアイデア検討からプロトタイプ開発にGeminiや他のAIを活用してみました。
１．マニュアルをWordPressで公開するか、専用のCMS等を検討すべきか？
○Geminiに作成させた比較表
| 項目 | WordPressがおすすめ | 専用システム（CCMS等）を検討すべき |
|---|---|---|
| 製品数 | 数点〜数十点程度 | 数百点以上のシリーズ展開 |
| 更新頻度 | 月に数回〜週に数回 | 毎日のように細かい部品情報が変わる |
| 多言語展開 | 2〜3言語程度（プラグインで対応可） | 10言語以上で同期が必要 |
| 執筆環境 | 事務担当者がWord感覚で書きたい | テクニカルライターが構造化データとして書きたい |
さらにWordPressの機能の使い方についてです。WordPressはもともとブログを書くためのツールです。ブログは記事がひとつひとつ独立していて、日記のように投稿した日付順に公開されます。これに対して、マニュアルのWebページは多数のHTMLを一組として扱います。Geminiに確認したところ、カスタム投稿タイプというWordPressに標準で備わっている「投稿（ブログ）や「固定ページ」とは別に、自分で定義した「新しい種類のページ枠」を設定すると良いとのことです。例えば「Manual」という名前のカスタム投稿タイプを設定します。
また記事を投稿順ではなく、指定の順序で公開する方法や、目次の作り方、など自分で調べるとかなり時間がかかる使い方もAIに聞けば瞬時に回答が得られます。こうした知識についてはAIに圧倒的な利があり、人間は到底かないません。但し、自分で確認しないと、AIの回答が根本的に誤っていることも少なくありません。
２．実装方法の検討
実装方法で一番のポイントは外部のHTMLファイルをWordPressにどのように投稿するかです。これも、Geminiに質問しました。次のようにREST APIを使った投稿プログラムをAIに作成させると良いだろうということになりました。
WordPress APIとの連携（ここが自動化の鍵）
手動でコピペする手間をなくすため、APIを連携させます。
アクション: WordPressの管理画面から「アプリケーションパスワード」を発行し、AIにAPI連携コードを書かせます。
AIへの指示: 「変換したHTMLファイルを、WordPressのREST APIを使って『非公開の下書き』として自動投稿する機能を作って」
３．実装段階
Geminiを相手に凡そ100回位こうしたQ&Aを繰り返して大雑把な要求項目を作成したうえで、実装段階に進むことになりました。
実装段階では、別の開発者をアサインして、コーディング用AIとしてCursorを使用してプログラムを開発、いろいろ試験を繰り返したうえで、デモレベルでは概ね使用可能となりました。
プロトタイプのデモなど、8月27日のCDシンポジウムのZoomウェビナーでご紹介予定です。
よろしければ、ぜひご視聴ください。
8月14日追記：本活用例のWebページが公開されました。
活用例：REST API1を使ってWordPressへ自動ポスト
次回：AIを利用するソリューション作成（4）自然言語処理のローカルAIを使い、PDFから名前を捜して墨消し
前回：新連載：AIを利用するソリューション作成（2） 目的としてのAIと手段としてのAI