2026-03-22

SwallowKit アップデート — 多言語バックエンド対応・VS Code 拡張機能＆ドキュメントサイト公開

以前の記事で紹介した、Azure 上の Next.js アプリ向けスキーマ駆動開発ツールキット「SwallowKit」ですが、あれから約1ヶ月でかなり大きなアップデートを行いました。

himanago.hatenablog.com

前回の記事の最後に書いていた「今後の展望」のうち、以下の2つを実現しました！

バックエンド（Azure Functions）の TypeScript 以外の言語への対応 → C#・Python 対応
コーディングエージェント向けのコード生成カスタム指示のサポート → AI フレンドリー機能（AGENTS.md 等の自動生成）

さらに、これらに加えて VS Code 拡張機能のリリース、ドキュメントサイトの公開、開発用シードデータ機能 など、開発体験を大きく向上させる機能追加も行っています。

特に多言語対応と開発用シードデータ対応により、幅広い場面で便利に使えるようになったんじゃないかなと思います！

この記事では、これらの新機能をまとめて紹介します。

新機能一覧

今回のアップデートで追加された主な機能は以下の通りです。

機能	概要
🌐 多言語バックエンド対応	Azure Functions で TypeScript に加え C#・Python を選択可能
🧬 OpenAPI スキーマブリッジ	C#/Python バックエンド向けに Zod → OpenAPI → 各言語モデル自動生成
🤖 AI フレンドリー	`AGENTS.md`、`CLAUDE.md`、`.github/copilot-instructions.md` を自動生成
🧩 VS Code 拡張機能	GUI ウィザード・右クリックスキャフォールド・ステータスバー・スニペット
🌱 開発用シードデータ	`create-dev-seeds` + `dev --seed-env` で Cosmos DB Emulator のデータを差し替え。ローカルでの動作確認でさまざまなデータパターンを簡単にできるようになった
📚 ドキュメントサイト	VitePress 製の英語/日本語ドキュメント公開

それぞれ詳しく見ていきます。

🌐 多言語バックエンド対応（C#・Python）

前回のリリースでは Azure Functions のバックエンドは TypeScript のみでしたが、C# と Python にも対応しました。

swallowkit init 時にバックエンド言語を選択できます。

npx swallowkit init my-app

フラグで直接指定すれば、非対話モードでの実行も可能です。

npx swallowkit init my-app --backend-language csharp

OpenAPI スキーマブリッジ

TypeScript バックエンドの場合は、Zod スキーマを直接 import して共有できますが、C# や Python では Zod を直接使えません。

そこで SwallowKit では、Zod スキーマ → OpenAPI → 各言語のモデルコード という変換パイプラインを自動で実行します。

shared/models/todo.ts (Zod)
        │
        ▼
functions/openapi/todo.openapi.json (OpenAPI)
        │
        ▼
functions/generated/csharp-models/  (C# の場合)
functions/generated/python-models/  (Python の場合)

swallowkit scaffold を実行するだけで、この変換が自動的に行われます。スキーマを変更した場合も、再度 scaffold を実行すれば OpenAPI と各言語のモデルが再生成されます。

フロントエンド・BFF は引き続き Zod を直接利用するため、TypeScript 側の型安全性はそのまま。バックエンドが異なる言語でも、OpenAPI を介して契約の整合性が保たれます。

🤖 AI フレンドリー

昨今、GitHub Copilot・Claude Code・OpenAI Codex などの AI コーディングエージェントを使った開発が一般的になってきています。

SwallowKit では、init コマンドでプロジェクトを初期化すると、複数の AI エージェント向け指示ファイルが自動生成されます。

ファイル	対象エージェント	内容
`AGENTS.md`	OpenAI Codex / 汎用エージェント	アーキテクチャ仕様・命名規則・CLI スキルなど
`CLAUDE.md`	Claude Code	クイックリファレンス + CLI コマンド一覧
`.github/copilot-instructions.md`	GitHub Copilot	主要ルールの要約（Copilot が自動読み込み）

さらに、GitHub Copilot 向けにはレイヤー別のルールファイルも生成されます。

.github/instructions/
├── shared-models.instructions.md      # shared/models/** 向けルール
├── bff-routes.instructions.md         # app/api/** 向けルール
└── azure-functions.instructions.md    # functions/** 向けルール

これにより、AI エージェントがコードを生成・修正する際に、SwallowKit のアーキテクチャと規約（BFF パターン、Zod スキーマ共有、レイヤー分離など）に従ったコードが出力されやすくなります。

🧩 VS Code 拡張機能

SwallowKit のすべての CLI コマンドを VS Code の GUI から操作できる拡張機能をリリースしました。

marketplace.visualstudio.com

コマンドパレットからの操作

Ctrl+Shift+P でコマンドパレットを開き、SwallowKit と入力すると、利用可能なコマンド一覧が表示されます。

コマンド	説明
`SwallowKit: Initialize New Project`	フォルダ選択 → プロジェクト名 → 各種設定をウィザード形式で入力
`SwallowKit: Create Model`	モデル名を入力して作成、作成後自動的にエディタで開く
`SwallowKit: Scaffold CRUD from Model`	モデルファイルを選んで CRUD コードを自動生成
`SwallowKit: Scaffold CRUD (API Only)`	UI コンポーネントなしで API のみ生成
`SwallowKit: Start Dev Server`	開発サーバーを起動（シードデータの選択も可能）
`SwallowKit: Stop Dev Server`	開発サーバーを停止
`SwallowKit: Create Dev Seed Templates`	シードデータテンプレートを生成
`SwallowKit: Provision Azure Resources`	Azure リソースをプロビジョニング

右クリックメニュー

エクスプローラーでモデルファイル（shared/models/*.ts）を右クリックすると、コンテキストメニューから直接 Scaffold を実行できます。

また、shared/models/ フォルダを右クリックすれば、新しいモデルの作成も可能です。

開発サーバーステータスバー

VS Code のステータスバーに SwallowKit の開発サーバー状態が表示されます。

停止中: ○ SwallowKit — クリックで起動
実行中: ▶ SwallowKit: Running（警告色の背景） — クリックで停止

ワンクリックで開発サーバーの起動・停止ができるので、ターミナルを開く手間が省けます。

後述のシードデータも選べます。

TypeScript スニペット

モデル定義でよく使うコードパターンをスニペットとして用意しています。

プレフィックス	説明
`skmodel`	SwallowKit Zod モデルのテンプレート
`skfield-string`	min/max 付き string フィールド
`skfield-number`	min 付き number フィールド
`skfield-boolean`	default 付き boolean フィールド
`skfield-enum`	enum フィールド
`skfield-array`	array フィールド
`sknested`	ネストされたスキーマ参照

たとえば skmodel と入力してタブキーを押すと、モデルの基本構造が一発で入力されます。

🌱 開発用シードデータ

ローカル開発時に、Cosmos DB Emulator のデータを定義済みの JSON から自動で差し替える機能を追加しました。

実際に SwallowKit をベースに開発している際、ローカルデバッグ時に使いたい DB のデータパターンをあらかじめ作っておくことで、Cosmos DB Emulator に入っているデータを入れ替えながら見て行く事ができるようになりました。

Zod スキーマで一気通貫の構造にしているからこそ、ここを SwallowKit コマンドでサポートするのも容易でした。

使い方

まず、シードデータのテンプレートを生成します。

npx swallowkit create-dev-seeds local

これで dev-seeds/local/ ディレクトリに、プロジェクトで定義されたモデルに対応する JSON テンプレートが生成されます。

dev-seeds/
  local/
    todo.json       ← shared/models/todo.ts に対応
    category.json   ← shared/models/category.ts に対応

JSON ファイルを編集して、開発用のデータを定義します。

[
  {
    "id": "seed-todo-001",
    "text": "最初の TODO",
    "completed": false,
    "createdAt": "2026-03-22T00:00:00.000Z",
    "updatedAt": "2026-03-22T00:00:00.000Z"
  },
  {
    "id": "seed-todo-002",
    "text": "2番目の TODO",
    "completed": true,
    "createdAt": "2026-03-22T00:00:01.000Z",
    "updatedAt": "2026-03-22T00:00:01.000Z"
  }
]

あとは --seed-env オプションを指定して開発サーバーを起動するだけです。

npx swallowkit dev --seed-env local

起動時に、JSON ファイルに対応するコンテナのデータが自動的にシードデータで置き換えられます。JSON ファイルが存在しないコンテナのデータはそのまま残ります。

複数の環境（local、staging-debug など）を用意しておけば、テストシナリオに応じた切り替えも簡単です。

VS Code 拡張機能を使えば、SwallowKit: Start Dev Server コマンド実行時にシード環境を選択するプロンプトが表示されるので、さらに便利です。

📚 ドキュメントサイト公開

SwallowKit の公式ドキュメントサイトを VitePress で構築し、GitHub Pages で公開しました。英語・日本語の両方に対応しています。

himanago.github.io

見た目はこんな感じ。GitHub Copilot にお願いして作ってもらいました。

以下のガイドを用意しています。

ページ	内容
Scaffold ガイド	CRUD コード自動生成の詳細な使い方
Zod スキーマ共有ガイド	スキーマ設計のベストプラクティス
CLI リファレンス	全コマンド・オプションの詳細
デプロイガイド	Azure へのデプロイ手順

CLI の使い方だけでなく、アーキテクチャの考え方やスキーマ設計のパターンなども含めて整理されているので、ぜひ参考にしてみてください。

まとめ

今回のアップデートで、SwallowKit は CLI ツールとしてだけでなく、VS Code 拡張機能やドキュメントサイトを通じて、より幅広い開発者にとって使いやすいツールキットに近づけたかなと思います。

前回の記事で「今後の展望」として挙げていた項目のうち、多言語バックエンド対応と AI フレンドリー機能を実現できました。

振り返ると、新機能としては以下が加わっています。

✅ Azure Functions バックエンドで C#・Python を選択可能に（OpenAPI ブリッジによるスキーマ連携）
✅ AI コーディングエージェント向け指示ファイル（AGENTS.md 等）の自動生成
✅ VS Code 拡張機能 — GUI ウィザード、右クリック Scaffold、ステータスバー、スニペット
✅ 開発用シードデータ — Cosmos DB Emulator のデータを JSON で管理・自動投入
✅ ドキュメントサイト — 英語/日本語対応の公式ドキュメント

まだ残っている「認証・認可のサポート」や「Next.js 初期化オプション対応」などについても引き続き取り組んでいきたいと思います。

フィードバックや改善のアイデアがありましたら、ぜひ GitHub リポジトリの Issues や、VS Code 拡張機能の Issues でお知らせください。

Next.js + Azure Static Web Apps + Azure Functions + Cosmos DB で効率よくアプリケーションを開発・ホストできるツールキット「SwallowKit」をリリースしました

Microsoft Azure Azure Static Web Apps Azure Functions Azure Cosmos DB SwallowKit TypeScript

昨今、アプリケーション開発そのものは AI の進歩により誰でも簡単にできるようになってきました。

アプリケーション開発が簡単にできても、その次のステップとして、アプリケーションを運用するためのインフラストラクチャを構築することが重要になってきています。

そこで今回、

開発者フレンドリーな PaaS / サーバーレスで
ベストプラクティスに沿った構成で

アプリ開発の土台からインフラまで一挙に作成・管理できるツールが有用と考え、Azure Static Web Apps + Azure Functions + Cosmos DB で Next.js を効率よく開発・ホストできるツールキット「SwallowKit」を開発しました。

github.com

npm に公開しているので、npx からすぐに利用できます。

https://www.npmjs.com/package/swallowkit

SwallowKit とは

SwallowKit は、Azure 環境に最適化されたスキーマ駆動開発ツールキットです。

Next.js アプリを Azure Static Web Apps にスタンドアロンモードでデプロイし、独立した Azure Functions バックエンドと接続します。

SwallowKit の特徴

アプリの全スタックをコードファーストで構築できるコマンドラインツール

swallowkit コマンドを使用して、アプリの全スタックをコードファーストで構築できます。

コマンド	説明
`npx swallowkit init <app-name>`	新しいプロジェクトを初期化します。最新の Next.js を使用してアプリを作成し、SwallowKit 専用の構成・設定を適用します。
`npx swallowkit create-model <model-name>`	データモデルを作成します。
`npx swallowkit scaffold <model-name>`	モデルから CRUD コードを自動生成します。フロントエンドの画面に加え、BFF レイヤーと、Azure Functions バックエンドのコードを生成します。
`npx swallowkit dev`	ローカル開発サーバー（Next.js + Azure Functions）を起動します。Cosmos DB Emulator を使用してローカルでの開発・デバッグが可能です。
`npx swallowkit provision -g <resource-group-name>`	init 時に選択された構成をもとに生成された Bicep コードを使用し、Azureにリソースをプロビジョニングします。

Zod スキーマの共有と Next.js API を BFF としてのみ利用する構成

最大の特徴は、Zod スキーマを共有することで、フロントエンドからデータベースまで一貫した型安全性を保証できる点です。

Next.js API ルートは BFF (Backend For Frontend) として制限され、ビジネスロジックは Azure Functions にオフロードされるため、クライアントとサーバーの明確な分離が実現されます。

昨年から、React Server Components (RSC) / Next.js の脆弱性について大きな話題となることが増えてきていますが、SwallowKit では Next.js API ルートを BFF として制限することで、このセキュリティリスクを最小限に抑えています。

さらに、この構成をとることでバックエンドのビジネスロジック部分を Azure Functions で記述できるようになり ¹ 、強力な入出力バインディングや各種トリガーなどをフル活用することができます。

Microsoft Foundry などの AI モデルをはじめ、Azure のさまざまなサービスとの連携させて機能を拡張していくことが可能です。

Bicep（IaC）＆ GitHub Actions または Azure Pipelines（CI/CD）による簡単デプロイ

自動生成される Bicep IaC と CI/CD ワークフローにより、Azure へのデプロイが簡単に行えます。

Static Web Apps + Functions + Cosmos DB による最小コストかつセキュリティも考慮したアーキテクチャ構成で、インフラを意識せずアプリ開発に注力することを目指しています。

Azure リソースの構成

SwallowKit でプロビジョニングされる Azure リソースは以下のようなイメージです。

使用イメージ

0. 下準備

Azure CLI と Azure Functions Core Tools をインストールしておきます。

Azure CLI をインストールする方法 | Microsoft Learn

Core Tools を使用してローカルで Azure Functions を開発する | Microsoft Learn

また、Cosmos DB Emulator をインストールしておきます。SSL 証明書の準備などが不要な vNext がおすすめです（SwalowKit はこれに最適化されています）。

learn.microsoft.com

Docker を使用している場合は、以下のコマンドで起動できます。

docker run --detach --publish 8081:8081 --publish 1234:1234 mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator:vnext-preview

1. プロジェクトの初期化

npx swallowkit init my-app
cd my-app

初期化時、使用する CI/CD パイプライン（GitHub Actions or Azure Pipelines）、Cosmos DB のプラン（Free Tier or サーバーレス）、VNET 統合有無を選択します。これらの選択は、後から npx swallowkit provision コマンドで Azure にリソースをプロビジョニングする際に使用される IaC コード（Bicep）に反映されます。

初期化で作成されるプロジェクト構造はこんな感じです。

Next.js の初期状態をベースに、Bicep と Functions のコードを追加しています。

2. モデルの作成

実際の開発は、モデル（Zod スキーマ）の作成から始まります。

例えば、TODO アプリを作る場合、カテゴリーと TODO のモデルを作成します。

npx swallowkit create-model category todo

できあがったコードには最低限のフィールドしか入っていませんが、必要に応じてフィールドを追加していきます。

import { z } from 'zod';

export const category = z.object({
  id: z.string(),
  name: z.string().min(1).max(50),
  createdAt: z.string().optional(),
  updatedAt: z.string().optional(),
});

export type Category = z.infer<typeof category>;

カテゴリーを TODO の親として紐付ける場合は、このようにネストさせて定義します。

import { z } from 'zod';
import { category } from './category';

export const todo = z.object({
  id: z.string(),
  text: z.string().min(1).max(200),
  completed: z.boolean().default(false),
  category: category.optional(), // 親子関係はネストで表現
  createdAt: z.string().optional(),
  updatedAt: z.string().optional(),
});

export type Todo = z.infer<typeof todo>;

3. コードの自動生成

npx swallowkit scaffold category
npx swallowkit scaffold todo

これで、フロントエンドの画面に加え、BFF レイヤーと、Azure Functions バックエンドのコードが生成されます。

4. ローカル開発サーバーの起動

npx swallowkit dev

ローカルで Next.js と Azure Functions の両方が起動し、Cosmos DB Emulator に接続されます。ブラウザで http://localhost:3000 を開くと、生成された CRUD 画面が表示されます。

自動生成されたコードを参考にしたりカスタマイズしたりしながら、アプリを開発していきます。

5. Azure へのプロビジョニング

Azure にリソースを作成します。

新しく作るリソースグループ名を指定して、以下のコマンドを実行します。

npx swallowkit provision -g my-resource-group

これで、Azure Static Web Apps、Azure Functions、Cosmos DB がプロビジョニングされ、Next.js アプリが Azure Static Web Apps にデプロイされます。

6. ソースコードのプッシュ

GitHub または Azure Repos にソースコードをプッシュします。

SwallowKit でプロビジョニングされたリポジトリには GitHub Actions または Azure Pipelines のワークフローが自動生成されています。

GitHub Actions の場合はプッシュ後すぐに CI/CD パイプラインが実行されますが、必要なシークレットが未登録のためいったん止めるか失敗を待ちます。

7. シークレットの登録

provision コマンドの実行後、以下のようにソースコードのビルド・デプロイのための CI/CD パイプラインの実行に必要なシークレットのキー／値ペアが出力されるので、GitHub Actions または Azure Pipelines のシークレットとしてすぐに登録できます。

📝 Next Steps:
  1. Configure CI/CD secrets/variables:

     [AZURE_STATIC_WEB_APPS_API_TOKEN]
       abc123def456ghi789jkl012mno345pqr678stu901vwx234yz567890abcdef

     [AZURE_FUNCTIONAPP_NAME]
       func-my-swallowkit-functions-abc123

     [AZURE_FUNCTIONAPP_PUBLISH_PROFILE]
       <publishData><publishProfile profileName="func-my-swallowkit-functions-abc123" publishMethod="MSDeploy" publishUrl="func-my-swallowkit-functions-abc123.scm.azurewebsites.net:443" msdeploySite="func-my-swallowkit-functions-abc123" userName="$func-my-swallowkit-functions-abc123" userPWD="aBcDeFgHiJkLmNoPqRsTuVwXyZ1234567890" destinationAppUrl="https://func-my-swallowkit-functions-abc123.azurewebsites.net" SQLServerDBConnectionString="" mySQLDBConnectionString="" hostingProviderForumLink="" controlPanelLink="http://windows.azure.com" webSystem="WebSites"><databases /></publishProfile><publishProfile profileName="func-my-swallowkit-functions-abc123" publishMethod="ZipDeploy" publishUrl="func-my-swallowkit-functions-abc123.scm.azurewebsites.net:443" userName="$func-my-swallowkit-functions-abc123" userPWD="aBcDeFgHiJkLmNoPqRsTuVwXyZ1234567890" destinationAppUrl="https://func-my-swallowkit-functions-abc123.azurewebsites.net" SQLServerDBConnectionString="" mySQLDBConnectionString="" hostingProviderForumLink="" controlPanelLink="http://windows.azure.com" webSystem="WebSites"><databases /></publishProfile></publishData>

8. CI/CD パイプラインの実行

シークレットの登録後、GitHub Actions または Azure Pipelines のワークフローを再度実行します（GitHub Actions は手動でトリガーできるよう設定済みです！）。

これで、Azure Static Web Apps に Next.js アプリがデプロイされます。

9. アプリの確認

Azure Static Web Apps の URL にアクセスして、アプリが正しく動作していることを確認します。

おわりに・今後の展望

SwallowKit は、Azure 環境に最適化されたスキーマ駆動開発ツールキットで、Next.js アプリを Azure Static Web Apps にスタンドアロンモードでデプロイし、独立した Azure Functions バックエンドと接続します。

Zod スキーマを共有することで、フロントエンドからデータベースまで一貫した型安全性を保証できる点が最大の特徴です。SwallowKit を使用することで、アプリの全スタックをコードファーストで構築でき、Azure へのデプロイも簡単に行えます。

AI コーディングエージェントによる開発と組み合わせれば、爆速でクラウドで動作するアプリケーションを手に入れることができると思います。

このツールキット、コンセプトの企画は昨年9月頭くらいから始めてその後試行錯誤しながら作ってきてようやく形になったものです。

上記で紹介した基本機能は実装できていて、公開版（本記事執筆時点の最新版 v1.0.0-beta.4）に含まれています。

まだまだ粗削りな部分も多いですが、今後ブラッシュアップしながら、以下のような機能の追加もしていきたいと思っています：

フロントエンド・バックエンドの一環した認証・認可のサポート
Next.js 初期化オプションへの対応
コーディングエージェント向けのコード生成カスタム指示のサポート
バックエンド（Azure Functions）の TypeScript 以外の言語への対応

もし触ってみた方がいらっしゃいましたら、感想やフィードバックをいただけると嬉しいです！

Static Web Apps に Next.js をホストすると、バックエンドは Azure Functions ではなくカスタマイズ不可の専用 App Service 環境になります。↩

2025-12-01

Microsoft Foundry Agent Service を使った LINE Bot をノーコードで構築する

Microsoft Azure Azure Logic Apps LINE Messaging API

本投稿は LINEDC Advent Calendar 2025 の1日目の記事です。

1日目なのに空席になっていたので、急いで書いています！！

Microsoft Foundry とは

これまで Azure AI Foundry として提供されていたサービスです。先日の Microsoft Ignite 2025 にて Microsoft Foundry への名称変更が発表されました。

Microsoft Foundry はさまざまな AI モデルやエージェントを作成・利用できるプラットフォームで、Azure サービスとの連携も容易です。

LINE Bot からつないでみよう

以前、ノーコード・ローコードサービスである Azure Logic Apps で LINE Bot を簡単に構築できるテンプレートを作りましたので、今回もこれを使って LINE Bot を作り、ノーコードで Microsoft Foundry Agent Service と連携してみます。

himanago.hatenablog.com

github.com

Logic Apps は Power Platform で使える「Power Automate」と同じ UI なので、そちらで慣れている人は特にすんなり使えると思います。

テンプレートから LINE Bot のバックエンド処理を作成

上記リポジトリの README 内のリプライ＞テキストのオウム返し＞「Deploy to Azure」から、カスタムデプロイ画面を開きます。

あらかじめ作っておいた Messaging API チャネルの ID とシークレットを入力してデプロイすると、オウム返しを行うフローが最初からつくられた状態で Logic Apps リソースができあがります。

あとは、Logic Apps の URL を Messaging API の Webhook URL として設定すれば準備 OK です。

Table Storage を作成する

エージェントとの対話は、「スレッド」という単位で行います。

今回は LINE のユーザーと1対1でスレッドを作成することにし、それを管理するために Table Storage を使います。

Cosmos DB などのデータベースサービスでももちろんよいですが、今回はより手軽な Table Storage を選択しています。

Azure の、Logic Apps と同じリソースグループに「ストレージアカウント」を作成し、ストレージブラウザーの「テーブル」で新しいテーブル threads を作成しておきます。

Logic Apps との接続をセキュアにするため、マネージド ID を使います。まず Logic Apps の「ID」からシステム割り当てマネージド ID をオンにし、その後ストレージアカウントの「アクセス制御 (IAM)」から Logic Apps のマネージド ID に対して「ストレージテーブルデータ共同作成者」のロールを付与しておきます。

これで、Logic Apps からテーブルへの操作が可能になります。

エージェントを準備する

Azure ポータルから「Microsoft Foundry」リソースを作成し、Foundry ポータルに遷移します。

そこでエージェントを作成しましょう。モデルを選ぶだけで簡単に用意できます。

Foundry ポータル上で、エージェントへの事前の指示（システムプロンプトですね）や複数エージェントとの連携、ツール連携などの定義ができます。

今回は割愛しますが、ここで使用するツールにも Logic Apps のフローが使えますので、全体的にノーコードでエージェントが作れるのでうれしいですね。

learn.microsoft.com

Logic Apps でエージェントとの対話を構築する

では、Logic Apps のフローを組み立てていきます。

フロー先頭の変数初期化のところに、２つ変数を追加しておきます。

あとは、For each＞条件＞True＞スイッチ＞ケース 1 : テキストの中を変えていきます。

Logic Apps からエージェントを利用するには、AI Foundry アクションを使っていきます（おそらく、近日中に Microsoft Founcry に名称が変更されるでしょう）。

全体的にはこんな感じ。

ポイントは、スレッドの作成はストレージからの取得失敗時にのみ行うことで、初回以外はストレージに格納したスレッドIDを使って会話を継続していけるようにしています。

また、「Get Run」も Until ループで回すことで、返答が生成され終わるのを待つことができます。

そのほかポイントになりそうなアクションの中身を貼っておきます：

LINE ユーザー ID。値の選択で２つ出てきますが、（たぶん）下に表示されるほうを使います。（間違えるとループが勝手に増えてしまうので、おそらく気づけます）

LINE でユーザーが送ってきた文章を、メッセージに渡しています。

最後の、返答部分は下記ドキュメントにならって body('List_Messages')['data'][0]['content'][0]['text']['value'] という式をセットしています。

learn.microsoft.com

動作確認

こんな感じで動きます！

ちゃんとマルチターンで会話が続いてますね。

その他

Logic Apps では、そのほか自律型エージェントや会話型エージェントを作成する方法もあります。

learn.microsoft.com

これらの機能を使えば、より高度なエージェントを簡単に作成できそうですね。

エージェントループ（反復的なプロセスを使用して、複雑な複数ステップの問題を解決）を LINE Bot から使っていくということも、いずれやってみたいところです。

2025-07-15

Microsoft MVP を再受賞しました。（2025）

Microsoft MVP

おかげさまで、今年も Microsoft MVP を再受賞できました。

今回で６度目の受賞となります。

同じく再受賞された MVP のみなさまも、おめでとうございます。

Microsoft Most Valuable Professionals

アワードのカテゴリは変わらず Microsoft Azure で、テクノロジ分野が Azure Application PaaS です。

Twitter にも書いたのですが、エリアについてはちょっと思うところがあり今年の活動は少し手広くやりたいなぁと思ってます。

おかげさまで今年も無事に Microsoft MVP を再受賞することができました！
今回は Azure Application PaaS のみ…今年はもう少し手広くやりたいなぁと思います！ #MVPBuzz pic.twitter.com/Gw0dnj6fGB
— ひらりん (Takumasa Hirabayashi) (@himarin269) 2025年7月10日

というのも、やっぱり Azure の強みは開発者フレンドリーな PaaS で、自分はそこが好きだし今後も使っていきたい・良さを知ってもらいたいと思っているのですが、
単純にその PaaS （たとえば Functions とか）の単体の使い方やパフォーマンスの引き出し方だったりを紹介するのは自分の役目ではないと感じていて、そこは公式のドキュメントやつよつよのエンジニアの方々に譲るべきで、自分の出る幕ではないなと思ってます。

そのかわりに自分がやっていきたいのはやはり複数のサービスとの連携や、いままでにない組み合わせのアイディアの提供、また手軽に PaaS の便利さを体験できるハンズオンなどです。

昨今は開発作業をかなり AI に任せていくことができるようになっていますが、公式のドキュメントやベストプラクティスとしては定着していない新しいアイディアや事例を作っていくことはまだまだ人間にしかできない価値があるのではと思っています。

これまでも LINE Bot 構築への応用例やちょっと斬新で面白いサービスの組合せ・使い方を見つけてこれたので、継続して力を入れていきたいと思っています。
その中で、Azure Application PaaS 以外の自分の中の軸となる技術エリアが見つかると嬉しいなという感覚です。
やっぱり AI 系かなと思う反面、いままであまり触っていなかった分野も組合せを試していけたら面白そうだなと思ってます。

とはいえ基本的にはいままでの延長のようなかたちで当面はやっていくと思いますので、勉強会等で見かけたら、その際は引き続きどうぞよろしくお願いします！

2025-03-31

Microsoft AI Tour Tokyo 2025 にてワークショップ/ハブのサポート＋シアターセッション登壇で参加しました

MSイベント Microsoft Azure Dify

はじめに

3/27 に東京ビッグサイトで開催された、Microsoft AI Tour Tokyo に参加してきました。

Microsoft AI Tour Tokyo とは Microsoft の AI 系サービスを中心としたセッション・ワークショップなどが多数開催される、Microsoft の大規模イベントの東京開催回です。

aitour.microsoft.com

今回は単なる参加者としてではなく、Microsoft MVP として３つの役割で参加させていただいたので、簡単にその感想などを書いておきます。

午前：基調講演

午前中は特に役割がなかったので、基調講演を聴講しました。

Microsoft のサティア・ナデラ CEO を初めて生で見れて感動。日本で講演してくれるのが素直にうれしいですね。

内容とアーカイブ動画はこちらで公開されているので、ぜひ見てみてください。

news.microsoft.com

午後：３つの役回り

午後はいろんな役目を仰せつかっていたのでバタバタと大忙しでした。

① Connection Hub 対応

まずは Connection Hub …つまりブースの対応でした。

Azure Database に関するブースの担当で、Cosmos DB やら Azure Database for PostgreSQL などなどのお話をさせていただきました。

今回午後シフトということで入っていたものの、後述する別の役割があり実際に入れたのは 1 時間ちょっとでしょうか。

それでも何組かのお客様とお話ができました。

AI に絡めた機能についてのお話が多かったですが、やはり話題の中心になるのはベクトル検索に対応した Cosmos DB ですね。

AI 関係なくとも Cosmos DB は便利だったわけですが、やはり AI / RAG に関連して注目度は高いと思います。

ベクトル検索という意味では PostgreSQL にも注目だと思うので、個人としてもこのあたりはもっと活用していきたいですね。

（Azure Database for PostgreSQL のほか Cosmos DB for PostgreSQL も出てきたので選択肢も増えました）

② ワークショッププロクター

75 分のワークショップ 2 回分をサポートで入りました。

ワークショップの内容はこちら。

github.com

Azure AI Foundry からいろいろなモデルを使ってみるという内容で、プロンプトエンジニアリングやその他の活用テクニックなども紹介されており、初心者にはかなり有用と思います。

いちおう、Deploy to Azure ボタンから自身の Azure 環境へデプロイすることも可能なのですが、モデルバージョンが若干古く動かないところがあったので、こちらにそこだけ直したものを載せてます。

もし興味があれば使ってください。

③ シアターセッション登壇

個人的に準備も含め一番大変だったのはこれです。

Azure上でDifyを活用したAIアプリケーションの構築

今回は「Azure 上での Dify を活用した AI アプリケーション構築」と題して、Azure らしい構成で Dify をクローズドにホストして使うという内容です。

資料はこちら。

www.docswell.com

こちらの登壇は 15 分間でデモ込みでお話ししましたが、15分では語りつくせないことがいろいろあるので、内容についてはまたあらためて別記事でも詳しくまとめたいと思います。

下記リポジトリに、セッション内で紹介した Dify を Azure に一発でデプロイできるスクリプトを公開しています。

今回のセッションに向けて、最新版の Dify を動かすためかなり試行錯誤をして作ったものになります。

クローズドな Dify 環境を用意したいという場合に有用だと思うので、ぜひ使ってみてほしいです。フィードバックもお待ちしています。

github.com

2024-12-04

GitHub の機能だけで LINE ミニアプリを作ってみる！

GitHub Codespaces GitHub Actions GitHub Pages LINE ミニアプリ LIFF

はじめに

本記事は LINEDC Advent Calendar 2024 の 4 日目の記事です。

ここだけあいてたので、急遽書きました…！

LINE ミニアプリとは

LINE アプリ内で動作させることのできるミニアプリで、実体は LIFF（LINE Front-end Framework）を使って作られる Web アプリケーションです。

これまで審査・認証を経なければ公開できなかったのですが、機能制限はあるものの未認証で公開できるようになり、気軽に試したり個人開発して個人的に使ったりということがしやすくなりました。

GitHub の機能だけで作ってみよう

ということで、できるだけ気軽に開発できるよう、ローカル開発環境も使わず、ブラウザのみで LINE ミニアプリを作ってみようと思います。

使うのは GitHub です。

GitHub Codespaces で開発をし、GitHub Actions を使ってビルドして GitHub Pages にデプロイ・公開します。

これにより、ブラウザだけで LINE ミニアプリを作って公開できます！

まずは LINE ミニアプリチャネルを作る

それではまずは、LINE Developers コンソールからミニアプリのチャネルを作ります。

まずはチャネル作成で「LINEミニアプリ」を選択。

チャネル名や説明など、必要事項を入力し各種規約に同意して作成をします。

チャネルができたら、「ウェブアプリ設定」のタブ内にある「LIFF URL」を確認します。

開発用、審査用、本番用の３つの URL がありますが、今回はお試しの個人利用ということで開発用を使っていきます。

この URL の最後のところの文字列（グレーで隠している部分）を控えておきます。これが「LIFF ID」です。

GitHub Codespaces で開発！

では、アプリを開発していきましょう。

ブラウザだけで VS Code を使った開発ができる GitHub Codespaces を使っていきます。

GitHub にサインインし、Codespaces のページを開きます。

https://github.com/codespaces

今回は React を使おうと思っているので、こちらのテンプレートを使ってみます。

これを使えば、開いたときから React 開発ができる状態になっていてとても便利です。

開くとこんな感じ。

App.jsx を LIFF アプリにしていきます。

まずはターミナルで（実行中のアプリを止めてから）

npm install --save @line/liff

を実行。

App.jsx の中身を以下に差し替えます。

import { useEffect, useState } from "react";
import liff from "@line/liff";
import "./App.css";

function App() {
  const [message, setMessage] = useState("");
  const [error, setError] = useState("");
  const [name, setName] = useState("");

  useEffect(() => {
    liff
      .init({
        liffId: import.meta.env.VITE_LIFF_ID
      })
      .then(() => {
        setMessage("LIFF init succeeded.");
        liff.getProfile()
          .then((profile) => {
            setName(profile.displayName);
          })
          .catch((err) => {
            console.log("error", err);
          });
      })
      .catch((e) => {
        setMessage("LIFF init failed.");
        setError(`${e}`);
      });
  });

  return (
    <div className="App">
      {message && <p>{message}</p>}
      {error && (
        <p>
          <code>{error}</code>
        </p>
      )}
      {name && <p>こんにちは、{name}さん</p>}
    </div>
  );
}

export default App;

また、vite.config.js の中身を以下に差し替えます。

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react()],
  base: process.env.VITE_BASE_URL || '/',
});

これは GitHub Pages にデプロイするときに必要な設定です。

ここまでできたらコードはいったん完成です。

コミットして、

「Branch の発行」から GitHub にリポジトリとして発行します。

GitHub Actions で GitHub Pages にデプロイ！

続いて公開に向けての設定です。

Settings ＞ Pages で GitHub Actions からデプロイするように設定します。

「create your own」をクリックし、CI/CD の設定を作っていきます。

ファイル名を main.yml にし、中身を以下のようにします。

VITE_LIFF_ID のところには、さきほどのミニアプリの URL 内の LIFF ID の値を入れます。

name: Deploy GitHub Pages

on:
  push:
    branches: ['main']

  workflow_dispatch:

permissions:
  contents: read
  pages: write
  id-token: write

concurrency:
  group: 'pages'
  cancel-in-progress: true

jobs:
  build:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Use Node.js 18
        uses: actions/setup-node@v4
        with:
          node-version: 18
          cache: 'npm'
      - run: npm ci

      - name: Build
        run: npm run build
        env:
          VITE_BASE_URL: /${{ github.event.repository.name }}/
          VITE_LIFF_ID: ここにLIFF ID をいれる

      - name: Upload static files as artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: 'dist/'

  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4
      
      - name: Print deployment URL
        run: |
          echo "Deployed to: ${{ steps.deployment.outputs.page_url }}"