Cloud RunとAgent Runtimeでブログの自動コーディングアプリ！【使用編】

1. はじめに（前回のおさらい）

前回の「実装してみた編」では、Cloud Run × Agent Runtimeを使って、Word原稿を社内フォーマットのHTMLへ自動変換するアプリを構築しました。今回はいよいよ、そのアプリに実際の原稿を投げ込み、HTMLが出てくるまでの様子をご紹介します。

まずは全体像を、ひとことで振り返っておきましょう。

要点は「入口はIAPで固く、Agentの権限は最小に、受け渡しはGCSで疎結合に」。この3原則が実際に動かすとどう効いてくるのか、見ていきます。

2. Webアプリへのアクセス（認証されたユーザとそうでないユーザ）

まずは「そもそも中に入れるのか」から確認します。ゼロトラストの効き目を体感するには、あえて2種類のユーザーで試すのが一番です。

許可されていないユーザーの場合

IAPのアクセス権を付与していないアカウントでアプリのURLを開くと、アプリの画面は一切表示されず、Googleの認証・認可フローで弾かれます。結果として、バックエンドのCloud Runには到達すらできません。URLを知っていても中身には触れられない――ネットワークではなく“アイデンティティ”で守られていることが体感できます。

図 1　許可されていないユーザーはアクセスできない

許可されたユーザーの場合

IAPで許可したアカウントでアクセスすると、認証を通過してアプリのUIが表示されます。ここで初めて、ファイルのアップロード欄や「生成開始」ボタンが使えるようになります。認証を通った人だけが機能に触れられる、という当たり前を、プラットフォーム側の設定だけで実現できているのがポイントです。

図 2　認証を通過したユーザーに表示されるアプリ画面

3. 実際に原稿をコーディングしてみた！

いよいよ本番です。使い慣れたWordで書いた原稿を投げ込んで、社内フォーマットのHTMLが出てくるまでを追います。

原稿をアップロードして「生成開始」を押す

許可ユーザーとしてログインし、見出し・箇条書き・強調を含む原稿ファイルをアップロードします。ファイルは裏側でGCSに保存され、「生成開始」を押すと、Agent Gateway → Agent Runtimeの順にAgentが呼び出されます。画面には進捗が順に表示されます。

図 3　原稿をアップロードして生成した様子

安全なダウンロードまで面倒を見る

生成したHTMLは、ただGCSに置くだけではありません。ブラウザに“強制ダウンロード”を指示するメタデータを付け、さらにIAM権限を持つ人だけがアクセスできる直リンクを返しています。公開URLをばら撒くのではなく、ログイン＆権限のある人だけがダウンロードできる状態を保っています。

# agent.py（生成HTMLの保存とリンク生成）
out_blob.upload_from_string(html_content,
        content_type="text/html; charset=utf-8")
# ブラウザに「表示ではなくダウンロード」を指示
out_blob.content_disposition = f'attachment; filename="{name}"'
out_blob.patch()
# IAM権限のある人だけがDLできるセキュアな直リンク
return f"[生成されたHTMLファイル]({direct_url})"

出てきたHTMLを確認する

生成されたHTMLをダウンロードして中身を確認します。見出しの階層（h2・h3）、段落・箇条書き・強調のマークアップ、画像や目次の型が、社内フォーマット通りになっているか。そしてhead・CSS・ヘッダー・フッターが1文字も変わっていないか。テンプレートを軸にし、プロンプトで「骨格は触るな、本文だけ差し替えろ」と厳命しているため、誰がやっても同じ社内フォーマット準拠の出力が得られます。以下画像は、このブログの「はじめに」部分のコードです。

図 4　自動生成された社内フォーマット準拠のHTML

これまで人が目視でコピペしていた工程が、「アップロード → ボタン → ダウンロード」の3ステップに凝縮されました。体感でも数分の作業が実質1分ほどに短縮され、出力のブレも無くなりました。

4. Webアプリ化のメリット

ここまで、実際にアプリを使ってHTMLを生成する様子を見てきました。ところで、「同じことはGeminiやM365 Copilotに直接お願いすればできるのでは？」と思われた方もいるかもしれません。しかし、あえて“Webアプリ”という形にしたことには、大きなメリットがあります。それは、AIの使い方がピンとこない人でも、そもそもAIのライセンスを持っていない人でも、誰もが同じ品質のアウトプットを出せるようになる、という点です。

プロンプトを考えなくていい（AIの使い方に迷わない）

生成AIを使いこなすうえで最初の壁になるのが「プロンプト（指示文）」です。どんな言葉で、どんな順番でお願いすれば思い通りの結果になるのか――ここでつまずき、「AIはなんだか難しそう」と身構えてしまう方は少なくありません。

今回のアプリでは、この“うまいプロンプト”や社内テンプレートをアプリ側にあらかじめ組み込んでいます。利用者がやることは、Word原稿をアップロードしてボタンを押すだけ。プロンプトを一切考える必要がなく、AIに詳しくない人でも、熟練者が指示したのと同じ品質のHTMLが得られます。

GeminiやM365 Copilotのライセンスがなくても使える

もう一つ大きいのが、ライセンスの問題です。生成AIを業務で使おうとすると、通常はGeminiやMicrosoft 365 Copilotといった有償ライセンスを一人ひとりに割り当てる必要があります。全員分をそろえればコストもかさみますし、「まだライセンスを持っていないから使えない」という人も出てきてしまいます。

Webアプリ化しておけば、AIの実行はサーバー側（Agent Runtime）でまとめて行われます。利用者は自分のAIライセンスを持っていなくても、ブラウザからアプリにアクセスするだけでOK。IAPで許可されたメンバーであれば、ライセンスの有無にかかわらず、全員が同じAIの力を使えるようになります。

誰が使っても“一定品質”になる（属人化しない）

プロンプトやテンプレートをアプリ側に固定しているため、使う人のスキルや、その日の指示の書き方によって結果がブレることがありません。ベテランが使っても、入社したばかりの人が使っても、出てくるHTMLは同じ社内フォーマットに準拠したもの。「あの人にしか作れない」という属人化を防ぎ、チーム全体の底上げにつながります。

まとめると、Webアプリ化によって次のような価値が生まれます。

「AIを一部の詳しい人だけの道具」で終わらせず、「チーム全員の当たり前の道具」に変えられること。これこそが、Webアプリという形にした一番の狙いです。

5. すでに社内ブログでも活躍中！

最後に少しだけ裏話を。実はすでに公開されている弊社のGoogle Cloudブログの記事のいくつかは、このアプリによって作られたものです。（もしかすると、あなたが今読んでいるこの記事も…？）

「試しに作ってみた」で終わらせず、実際の制作フローに組み込んで運用しているのが、今回いちばんお伝えしたかったポイントかもしれません。小さなアプリですが、日々のHTMLコーディング作業を着実に肩代わりしてくれています。

6. まとめ

本記事では、構築したアプリに実際の原稿を投げ込み、社内フォーマットのHTMLが自動生成される様子をご紹介しました。あらためて、今回の取り組みで実現できたことを整理します。

「使い慣れたツールで書く」という人間の自由度はそのままに、面倒で属人的な変換作業だけをAgentに任せる――人とAIの役割分担のちょうどいい形を、この小さなアプリで実感できました。

ここまでお読みくださり、ありがとうございました！