WordPressにAIチャットボットを実装した話【Claude API連携】

2026.04.05 (更新: 2026.04.10)

「お問い合わせのハードルが高い」という課題、ずっと気になっていた。

フォームを開いて、名前と連絡先を入力して、内容を書いて送信する。依頼を考えている人にとっては意外と面倒な作業で、「まずちょっと聞いてみたい」という軽い質問はそこで詰まってしまう。

そこで、自分のポートフォリオサイト n-pc.jp に Claude API を使ったAIチャットボットを実装してみた。右下のボタンをクリックするとチャット画面が開き、サービス内容や料金感を気軽に質問できる、いわゆるAIコンシェルジュ的な仕組みだ。

この記事では、実装の全体像と、実際にハマったポイントを記録しておく。

なぜローカルLLMではなくクラウドAPI（Claude）にしたか

実はもともと、ローカルLLM（GemmaやLlamaなどのオープンソースモデル）で構築するつもりだった。自分のサーバーにAIモデルを置けば従量課金がかからないし、データも外部に出ないのでプライバシー面でも安心だ。

※「ローカルLLM」とは、クラウドサービスを使わず、自分のサーバーやPC上でAIモデルを動かす方式のことです。GemmaやLlamaなど、無料で使えるオープンソースのモデルがあります。

ただ、調べていくと現実的なハードルが見えてきた。

GPUサーバーが必要：ローカルLLMをまともな速度で動かすにはGPU付きのサーバーが要る。月額$50〜200ほどかかる
今のレンタルサーバーでは動かない：n-pc.jpはXserverの共有サーバー。AIモデルを常駐させるようなスペックはない
個人サイトの規模感に合わない：月に数十〜数百回の会話のためにGPUサーバーを借りるのはコスパが悪い

一方、クラウドAPI（Claude API）であれば今のWordPressサーバーにPHPファイルを1つ追加するだけで動く。追加サーバー代はゼロで、かかるのはAPIの従量課金のみ。個人サイトのアクセス規模なら月数百円で済む計算だ。

というわけで、まずはクラウドAPIで動くものを完成させて、アクセスが増えてコストが気になってきたらローカルLLMへの移行を検討する、という段階的なアプローチに切り替えた。設計上、LLMへのリクエスト部分だけ差し替えれば移行できるようにしてある。

全体の構成：PHPプロキシで安全に中継する

最初に大事なことを書いておく。APIキーを直接JavaScriptに書いてはいけない。

ブラウザ上で動くJavaScriptにAPIキーを埋め込むと、誰でもソースコードから読み取れてしまう。そのキーが悪用されると、身に覚えのない請求が来る。

今回の設計はこうなっている。

ブラウザ（JS）
  ↓ Fetch API でリクエスト
WordPress REST API（/wp-json/npc/v1/chat）
  ↓ PHPがサーバー側で処理
Claude API（Anthropic）
  ↑ 結果を返す
WordPress → ブラウザへ返却

フロントエンドはWordPressのサイトと直接やり取りするだけ。Claude APIのキーはサーバー側（wp-config.php）に置いてあり、外から見えない。この構成を「PHPプロキシ」と呼ぶ。

※「PHPプロキシ」とは、PHPが「橋渡し役」として外部のAPIとブラウザの間に入る仕組みのことです。ブラウザが直接APIを叩くのではなく、PHPを経由させることでAPIキーをサーバー側に隠せます。

実装の中身：functions.phpとfooter.php

バックエンド：WP REST APIにカスタムエンドポイントを追加

functions.php にエンドポイントを登録する。

add_action( 'rest_api_init', function () {
    register_rest_route( 'npc/v1', '/chat', [
        'methods'             => 'POST',
        'callback'            => 'npc_chat_handler',
        'permission_callback' => '__return_true',
    ] );
} );

※「エンドポイント」とは、APIにアクセスするためのURLのことです。今回であれば /wp-json/npc/v1/chat というURLにPOSTリクエストを送ると、AIへの問い合わせが始まります。

ハンドラ関数の中でやることは大きく3つ。

IPアドレスによるレート制限のチェック（1日50回まで）
Claude APIへのリクエスト組み立て（システムプロンプト + ユーザーのメッセージ）
APIからの返答をブラウザに返す

システムプロンプトには、NPCのサービス内容（WordPress制作、EC、ブランディング、3Dプリント等）を記載してある。「詳しいお問い合わせはこちら（URLリンク）」という誘導も含めることで、チャットボットが問い合わせ窓口の入口として機能するようにした。

フロントエンド：Vanilla JSで実装

チャットUIは footer.php にHTMLを追加し、CSSは style.css に記述した。フレームワークは使わず、素のJavaScriptだけで書いている。

※「Vanilla JS（バニラJS）」とは、ReactやVueなどのフレームワークを使わず、JavaScriptをそのまま素の状態で書くスタイルのことです。「バニラ＝プレーン」という比喩から来ています。

チャットパネルは右下に固定表示のフローティングボタンを置き、クリックで開閉する。このサイトは3テーマ（game / elegant / bold）を切り替えられる自作テーマになっていて、CSS変数を活用することでどのテーマでも自動的にデザインが合わさるようにした。

ハマったポイント3選

実装中につまずいた箇所を正直に残しておく。

1. APIクレジットの反映に時間がかかる

Claude APIを使うにはAnthropicのダッシュボードでクレジット（利用料金）を購入する必要がある。$5を入れたのに「credit balance is too low」というエラーが出続けて焦った。

結論としては、クレジット購入後すぐには反映されないことがある。しばらく待ったら何も変更していないのに動くようになった。焦ってキーを再発行したりWorkspaceを行ったり来たりする前に、少し待ってみるのがおすすめだ。

2. モデルIDの指定ミス

最初に claude-haiku-4-5-20241022 というモデルIDを指定したところ 404 Not Found が返ってきた。

自分のアカウントで実際に使えるモデルを確認したら、claude-sonnet-4-20250514 だった。利用可能なモデル名はAnthropicのダッシュボードで確認できる。

※「モデルID」とは、AIのバージョンや種類を指定する文字列です。同じClaudeでも軽量な「Haiku」、標準的な「Sonnet」、高性能な「Opus」といった種類があり、それぞれIDが異なります。

3. 日本語入力（IME）の問題

チャット入力欄でEnterキーを押すと、漢字変換の確定時にも送信が発火してしまう問題があった。

たとえば「WordPress」と入力しようとしてEnterで確定した瞬間に送信される、といった動作だ。

解決策は e.isComposing のチェックを入れること。

inputEl.addEventListener('keydown', function(e) {
    if (e.key === 'Enter' && !e.isComposing) {
        sendMessage();
    }
});

※「IME（アイエムイー）」とは、日本語や中国語など、アルファベット以外の文字を入力するための変換ソフトです。Windowsの「Microsoft IME」やMacの「かな入力」がこれにあたります。変換中はブラウザに isComposing: true というフラグが立つため、これを確認することで誤送信を防げます。

今後の展望

現時点では、AIが答えられる知識はシステムプロンプトに書いた内容だけだ。今後はRAG（検索拡張生成）を使って、ブログ記事や用語集をAIの知識源として読み込ませる仕組みを作りたいと考えている。

※「RAG（ラグ）」とは、Retrieval-Augmented Generation（検索拡張生成）の略です。AIが回答する前に関連するドキュメントを検索して参照する仕組みで、AIが「知らないこと」を補完できます。図書館で本を調べてから答えるイメージ。

また、コスト面ではSonnetより安価なHaikuが使えるようになれば切り替える予定だ。クライアント案件への応用も考えていて、「WordPress制作＋AIコンシェルジュ」をセットで提案できれば差別化になると思っている。

まとめ

ローカルLLMはGPUサーバーが必要。個人サイト規模ならクラウドAPI（従量課金）の方がコスパが良い
Claude APIはPHPプロキシ経由でWordPressに安全に組み込める
functions.phpにWP REST APIのカスタムエンドポイントを作るのが核心部分
CSS変数を使えばマルチテーマ対応も難しくない
APIクレジットの反映遅延、モデルID指定が実際のハマりポイントだった
日本語IME対応は e.isComposing チェックで解決できる

「サービスについてちょっと聞いてみたい」というニーズは、問い合わせフォームよりチャットの方が拾いやすい。実装コストはそれほど高くないので、ポートフォリオサイトに一つ置いておく価値はあると感じている。

n-pc.jp でいま実際に動いているので、気になる方はぜひ試してみてほしい。

※この記事はNPCの中の人の実務経験をもとに書いています。

ブログ一覧に戻る << BACK TO BLOG