非エンジニアのWeb管理者が、クライアントの入力業務負荷を軽減するため、生成AIを壁打ち相手に活用してAPIキー隠蔽を考慮したWordPressカスタムプラグインを約30分で構築・稼働させた実録です。

フロントエンド実装で発生するセキュリティ脆弱性をサーバーサイド（PHP）中継で回避する構成や、実務で使える対話型プロンプト運用の知見を技術者向けに整理しました。

お堅い話のようですが違います。
AIにプロンプトでまとめさせよう。→ だったらWebアプリじゃね？ → セキュリティが不安ならプラグインにしろ → AIに従ってたらできちゃった。

【非エンジニア実録】AIと壁打ちして30分でWordPressプラグインを自作した話〜APIキー露出対策とサーバーサイド中継〜

はじめに

普段はWebサイトの保守・運用やディレクションを主軸にしており、ゼロからPHPでアプリケーションコードをガシガシ組むような専任エンジニアではありません。

先日、クライアント業務のボトルネックを解消するため、生成AI（Gemini等）をペアプログラミングのパートナーとして活用したところ、わずか30分で要件定義・実装・セキュリティ対策を施したWordPress専用プラグインを完成・稼働させることができました。

特に、UIモックから実運用へ移行する際に必ず直面する「フロントエンドにおけるAPIキー露出問題」を、WordPressのサーバーサイド（PHP）を活用してどのように安全に処理したか、技術的な流れと知見をまとめます。

背景と課題：クライアントの入力負荷軽減

クライアントワークにおいて、「エンドクライアントから自社紹介の骨子テキストを提出してもらう」という定常業務がありました。

しかし、白紙の状態から文章を起こすのは相手にとって非常に負荷が高く、提出遅延の原因になっていました。

当初の検討と技術的変遷

プロンプト直接配布案

外部公開情報をまとめるプロンプトをクライアントに配布。
課題：ITリテラシーに依存し、一般担当者にプロンプト操作を強いるのはUXとして不親切。

Webアプリ（Canvas等）埋め込み案

入力フォームを持つWebUIをAIで生成し、WordPressサイトに埋め込み。
課題：固定ロジック（診断テスト等）は動くが、外部検索や動的LLM出力をフロント単体で処理しようとすると制約に突き当たる。

クライアントサイド直接API連携案

JavaScript経由で直接外部API（LLM等）へfetchする構成を検討。
課題：ブラウザ側にAPIキーがハードコード（または露出）し、重大なセキュリティインシデントに直結する。

WordPressプラグイン化（採用）

サーバーサイド（PHP）でAPIキーを保持・秘匿化し、バックエンドから外部APIへリクエストを中継。

システム構成とセキュリティ対策

構成図

ブラウザ側から外部APIへ直接リクエストを送るアンチパターンを避け、WordPressのバックエンドをプロキシとして機能させました。

[クライアントブラウザ (JS)]
       │  ▲
       │  │ ① 入力データ送信 / レスポンス受取（非同期通信）
       ▼  │
[WordPress サーバー (自作プラグイン / PHP)]
  ※ APIキーはサーバーサイドで安全に保持・隠蔽
       │  ▲
       │  │ ② サーバー間通信 (wp_remote_post / cURL)
       ▼  │
[外部 API (LLM・検索サービス等)]

なぜプラグイン化が最適解だったのか

フロントエンド完結のSPAや静的スクリプトでAPIキーを扱う場合、難読化してもブラウザのネットワークタブを見れば容易に抽出されてしまいます。APIキーが漏洩すれば、クオータの枯渇や高額請求につながる致命的なリスクとなります。
ま、今回はGoogleAIstudioの無料キーなので制限ですみますが。

今回は既存のWordPress環境があったため、以下のメリットを享受するためにプラグイン化を選択しました。

サーバーサイド（PHP）で環境変数または設定テーブルからAPIキーを読み込むため、キーがクライアントに一切露出しない
プラグインヘッダーを記述した単一PHPファイルを wp-content/plugins/ に配置するだけで即時デプロイ可能
万が一PHP致命的エラー等が発生しても、FTP/SSHから対象ディレクトリ名を変更・削除するだけで安全にロールバック可能

実装ステップ（所要時間：約30分）

1. 要件定義をAIに投げる

AIに対し、以下の具体的な要件を自然言語で提示しました。

フロントエンドに入力用フォーム（会社名・キーワード等）をショートコード等で描画する
フォーム送信時、nonce検証を行った上でサーバーサイド（PHP）へ非同期送信する
PHP側でAPIキーを付与し、外部APIのエンドポイントへPOSTリクエストを投げる
外部APIから返ってきた要約結果をパースし、フロントのテキストエリアに描画する

2. コード生成とディレクトリ配置

AIから出力されたコードを検証し、以下の構造で配置しました。

wp-content/plugins/
└── custom-company-summarizer/
    └── custom-company-summarizer.php

PHPの冒頭には、WordPressがプラグインとして認識するためのヘッダーコメントをAIに出力させています。

<?php
/**
 * Plugin Name: Custom Company Summarizer
 * Description: 外部APIと安全に連携して企業紹介文の骨子を自動生成するプラグイン
 * Version: 1.0.0
 * Author: 桑野一哉
 */

if (!defined('ABSPATH')) {
    exit; // 直接アクセス禁止
}

// 内部ロジック（Ajaxハンドラ、wp_remote_post処理、ショートコード登録）

FTPでサーバーへアップロード後、WordPress管理画面のプラグイン一覧から「有効化」をクリック。依存関係の問題もなく一発で稼働しました。

3. AIによる対話型リファクタリング

実際に動かしながら、チャットベースで差分パッチを作成させました。

「この入力項目は不要なので削除して、システムプロンプト側の変数を整理して」
「返答の文量が短すぎるので、出力構造（会社概要・強み・事業内容）をプロンプト側で明示的に指定して」

修正指示を出すたびにAIが該当ブロックの書き換えコードを提示してくれるため、数分単位でブラッシュアップが完了しました。

非エンジニアが安全に実装を完遂できた理由

プログラミングを本職としない立場でありながら、短時間で本番稼働まで安全に持ち込めた要因は2点あります。

インフラと運用の「境界線」を把握していたこと
コードの文法を丸暗記していなくても、「WordPressがどのようにファイルをロードするか」「エラーが起きた場合にどのサーバーログを確認し、どうファイルを退避させるか」という運用の安全弁を理解していたため、過度に恐れず実装に踏み切れました。
AIを「コード自動生成機」ではなく「アーキテクチャの相談相手」にしたこと
「これで動くか」だけでなく、「この実装はセキュリティ的に問題ないか？」「APIキーを隠すための最適なWordPressの標準機能は何か？」と壁打ちしたことで、危険な実装を回避して正しいアプローチ（プラグイン化による中継）へ素早く舵を切ることができました。

おわりに

社内開発リソースが潤沢でない中小企業や受託の現場では、「ちょっとした業務効率化ツールのために開発案件を立ち上げる」ことはコスト的に見送られがちです。

しかし、構造的な安全性を理解しているディレクターや管理者がAIに伴走役として指示を出せば、現場の課題を解決するマイクロツールを即日自前で組み上げられる環境が整っていることを実感しました。

AIにすべてを丸投げするのではなく、セキュリティやインフラの要所を押さえながら「協打ちパートナー」として活用していくアプローチは、現場のエンジニアリング／改善活動において非常に実用的ですね。