はじめに こんにちは、サイオステクノロジーの佐藤 陽です。 今回はAzure Functionsを利用してMCPサーバーを構築する方法についてご紹介します。 Azure Functionsを利用してMCPサーバーを構築するためのExtensionである Microsoft.Azure.Functions.Worker.Extensions.Mcp の GA版(v1.0.0) が2025年10月9日にリリースされました！ 今回のブログでは、このGA版を使った実装方法を解説していきます。 MCPサーバーって何？という方 Azure FunctionsでMCPサーバーを構築したい方 preview版からGA版への移行を検討している方 といった方は是非最後までご覧ください！ サンプルコード 今回解説するコードをGitHubにて公開しています。 DevContainerですぐ動くような形となっていますので、是非お試しください。 GitHubリポジトリ： azure-functions-mcp-server-sample なお、元のDevContainerとしては、しばやんさん作成の Template を利用させていただいておりますmm MCPとは MCP（Model Context Protocol） は、AIモデルが外部のツールやデータソースとやり取りするための標準化されたプロトコルです。 MCPの詳細に関しては色々なところで分かりやすく解説されているので、今回の記事では説明を割愛します。 弊社の武井さんの Youtube や、KAGのみのるんさんの 資料 などが非常に分かりやすいので、ぜひこちらご覧ください！ 今回は、上記の記事でも紹介されている MCPサーバー をAzure Functions上で実装していきます。 環境構築 プロジェクトのセットアップ サンプルコードを利用するする場合は、上述のクローン手順に従ってください。 一から作成する場合は、以下の手順で進めます。 新規プロジェクトの作成 Azure Functionsのプロジェクトを新規作成する func init mcp-server --worker-runtime dotnet-isolated これにより、.NET Isolated Workerを使用したAzure Functionsプロジェクトが作成されます。 必要なパッケージのインストール MCP拡張機能パッケージをインストールする dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.0.0 注意点 GA版のMCP拡張機能を使用するには、 Microsoft.Azure.Functions.Worker のバージョンを 2.1.0以上 にする必要があります。 プロジェクトファイル（ .csproj ）を確認し、以下のバージョンが設定されていることを確認してください： < PackageReference Include = "Microsoft.Azure.Functions.Worker" Version = "2.1.0" /> < PackageReference Include = "Microsoft.Azure.Functions.Worker.Extensions.Mcp" Version = "1.0.0" /> 変更後パッケージの復元を行います。 dotnet restore 実装 ここまでくれば環境構築完了です。 MCPサーバーの実装を始めていきましょう！ 今回作成するMCPツールについて 今回は「MCPサーバーとは何か」「どう実装するか」を理解することにスポットに当て、非常にシンプルなツールを作成します。 私が普段YouTubeで配信している「 ツール・ド・Azure 」という技術解説シリーズがあるのですが、 今回のMCPツールでは、この各回のタイトル情報を取得する機能を実装します。 MCPトリガー関数の作成 それでは、実際にMCPツールとして公開する関数を作成していきます。 ベースとして一度HTTPトリガーの関数を追加し、それをベースにMCPトリガーに修正していくのが良いかと思います。 新しいファイル TourDeAzureTrigger.cs を作成し、以下のコードを記述します。 この関数は、AIエージェントが「ツール・ド・Azureの第N回のタイトルは何？」と質問したときに、適切なタイトルを返すツールを想定します。 using Microsoft.Azure.Functions.Worker; using Microsoft.Extensions.Logging; using Microsoft.Azure.Functions.Worker.Extensions.Mcp; public class TourDeAzureTrigger { private readonly ILogger<TourDeAzureTrigger> _logger; public TourDeAzureTrigger ( ILogger<TourDeAzureTrigger> logger ) { _logger = logger; } [ Function(nameof(GetTourDeAzureTitle)) ] public string GetTourDeAzureTitle ( [McpToolTrigger( "get_tour_de_azure_title" , "Gets title about the Tour de Azure." )] ToolInvocationContext context, [ McpToolProperty ( "edition" , "The edition number." , isRequired: true )] int edition) { return edition switch { 1 => "AI Document Intelligenceに入門しよう！" , 2 => "Azure AI Searchのインデクシングに入門しよう！" , 3 => "Azure上にRAGシステムを構築しよう！" , 4 => "RAGの性能を評価しよう！" , 5 => "安全なAIアプリケーションを構築しよう" , _ => "To Be Continued..." }; } } コードの詳細解説 実装したコードの各部分について詳しく見ていきましょう。 McpToolTrigger属性 [ McpToolTrigger( "get_tour_de_azure_title" , "Gets title about the Tour de Azure." ) ] 第1引数 ( get_tour_de_azure_title ): AIエージェントが呼び出すツール名 第2引数: ツールの説明文（AIがこのツールの用途を理解するために重要） ToolInvocationContext MCPツールの呼び出しコンテキスト情報を保持 McpToolProperty属性 [ McpToolProperty( "edition" , "The edition number." , isRequired: true) ] edition : パラメータ名 "The edition number." : パラメータの説明文 isRequired: true : 必須パラメータとして設定 Program.csの設定 次に、 Program.cs でMCPツールの設定を行います。 using Microsoft.Azure.Functions.Worker; using Microsoft.Azure.Functions.Worker.Builder; using Microsoft.Extensions.DependencyInjection; using Microsoft.Extensions.Hosting; var builder = FunctionsApplication.CreateBuilder(args); builder.ConfigureFunctionsWebApplication(); builder.Services .AddApplicationInsightsTelemetryWorkerService() .ConfigureFunctionsApplicationInsights(); builder .ConfigureMcpTool( nameof (TourDeAzureTrigger.GetTourDeAzureTitle)) .WithProperty( "edition" , "int" , "The edition number." , required: true ); builder.Build().Run(); ※preview版では、以下のメソッド呼び出しが必要でしたが、こちらがGA版では不要となりました。 builder.EnableMcpToolMetadata(); ConfigureMcpToolの詳細 第1引数 : 関数名(  nameof(TourDeAzureTrigger.GetTourDeAzureTitle) ) WithProperty : プロパティの詳細定義 パラメータ名 型情報 ( "int" , "string" など) 説明文 required : 必須かどうかのフラグ 動作確認 実装が完了したら、実際に動作確認を行っていきます！ Azuriteの起動 Azure Functionsはローカル実行時にAzure Storageが必要です。 ローカル環境ではストレージエミュレーター「Azurite」を使用します。 VSCodeの画面で 「Azurite: Start」 を実行します Azure Functionsの起動 次に、Azure Functionsを起動します： func start 正常に起動すると、コンソールに以下のような出力が表示されます。 エンドポイントが公開されていればOKです この後、「http://localhost:7071/runtime/webhooks/mcp」のエンドポイントを利用しますので、こちらを控えておいておいてください。 Azure Functions Core Tools Core Tools Version: 4.3.0+df07acf9d837d635d1efc2c973225f4f1c8a4333 (64-bit) Function Runtime Version: 4.1042.100.25374 Found /workspaces/azure-functions-mcp-server-sample/mcp-server/mcp-server.csproj. Using for user secrets file configuration. MCP server endpoint: http://localhost:7071/runtime/webhooks/mcp MCP server legacy SSE endpoint: http://localhost:7071/runtime/webhooks/mcp/sse Worker process started and initialized. Functions: GetTourDeAzureTitle: mcpToolTrigger For detailed output, run func with --verbose flag. Postmanでの疎通確認 今回はPostmanを使って、MCPサーバーとの簡単な疎通確認を行います。 Postmanの設定手順 Postmanを起動 新しいリクエストを作成し、プロトコルとして「MCP」を選択 サーバーのURL( http://localhost:7071/runtime/webhooks/mcp )を入力し、接続ボタンを押す ツールの確認 Postmanに get_tour_de_azure_title ツールが表示されることを確認 ツールの実行 パラメータ edition に値（例: 1 ）を設定 実行ボタンをクリック 期待される結果 パラメータ edition=1 で実行した場合 { "content" : [ { "type" : "text" , "text" : "AI Document Intelligenceに入門しよう！" } ] }   これでローカル環境にMCPサーバーが立ち上がり、疎通できていることが確認できました。 まとめ 今回は、Azure FunctionsでMCPサーバーを構築する方法をご紹介しました。 ただし今回は「はじめの一歩」レベルであり、LLMも絡んでいませんし、Agentic感も一切ありません。 そこで次のステップとしては、以下のような取り組みを考えています GitHub CopilotやClaude等のAIエージェントとの連携 複数のMCPツールを組み合わせた複雑なワークフローの実装 これらについては、また別の機会にご紹介していきたいと思います。 ではまた！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Azure FunctionsでMCPサーバーを構築するためのはじめの一歩【MCP Extension v1.0.0版】 first appeared on SIOS Tech. Lab .

この記事について 対象読者 : 前回の記事でOAuth2.0+PKCEの認証フローは理解したけど、取得したトークンをどう管理すればいいかわからない。X APIで自動投稿システムを作りたい人 ゴール : アクセストークンとリフレッシュトークンの違い、リフレッシュトークンの使い捨て性質を理解して、正しいトークン管理が実装できる X API OAuth 2.0のトークン管理をカフェの会員システムの比喩でふんわり解説。リフレッシュトークンの使い捨て性質から、クッキーvsデータベース保存の選択基準、よくある実装ミスまで初心者にもわかりやすく図解。セキュリティ対策とエラーハンドリングも網羅した実践的ガイド。 初めに ども！XのAPIを使用したアプリケーション開発にまつわるブログ執筆を爆速で仕上げ中の龍ちゃんです。最近は弊社のブログも活気がついてきて、取り残されないように頑張ってブログ執筆しています。前回は「 ふんわり始めるX API認証｜OAuth2.0とPKCEを初心者向けに図解解説 」でXでのOAuth2.0認証について解説しました。今回は、X APIにアクセスするためのトークンにまつわる話を解説しようと思います。 実装に入る前にトークンの概念は理解しておいたほうが良いです！しっかり入門していきましょう。 カフェの会員システムで理解しよう 前回との接続：ラーメン屋からカフェへ 前回はラーメン屋の券売機で認証フローを理解しましたね。今回は、その続きとして「カフェの会員システム」で考えてみましょう。 【前回】ラーメン屋の券売機 1. 券売機に申請 → 本人確認 2. 引換券をもらう(認可コード) 3. 窓口で食券に交換(トークン) 【今回】カフェの会員システム 1. 会員登録完了 → 会員カードをもらう 2. 2時間限定のドリンクチケットをもらう 3. チケットでドリンクを注文 4. チケット期限切れ → 会員カードで新しいチケットをもらう カフェの流れ それでは、カフェでの1日の流れを見ていきましょう。 ここで重要なのは、 会員カードも新品に交換される という点ですね。これが今回のテーマである「使い捨て性質」です。 登場人物の整理 用語 カフェの例 説明 アクセストークン 2時間限定ドリンクチケット API呼び出しに使う短命なチケット リフレッシュトークン 会員カード 新しいチケットをもらうためのカード(使うたび交換) X API カフェのカウンター サービス提供者 この比喩を頭に入れて、それぞれのトークンを詳しく見ていきましょう。 アクセストークン：2時間限定ドリンクチケット アクセストークンでできること 結論から言うと、 アクセストークンがあればX APIにアクセスできます 。 無料版のX APIでは、以下の操作が可能です： 操作 できること Xへの投稿 ツイートを投稿する、リプライを送る 自分の情報取得 プロフィール情報、ユーザー名などを取得 権限管理 スコープで「投稿のみ」「読み取りのみ」など範囲を制限 有料版になると、投稿の分析やアナリティクス情報の取得など、より高度な機能が使えるようになりますね。今回作っているサービスはXへの投稿を自動化するものなので、無料版でも十分実現できます。 カフェの例で言うと ： ドリンクチケット(アクセストークン)を見せる = API呼び出し ラテを注文(ツイート投稿)、会員情報確認(ユーザー情報取得) シンプルですよね。 有効期限：2時間 アクセストークンの有効期限は**約2時間(7200秒)**です。 00:00 OAuth認証完了 → アクセストークンA取得 ✅ │ API呼び出し可能 │ 01:00 まだ有効 ✅ │ API呼び出し可能 │ 02:00 期限切れ ❌ │ API呼び出し失敗 │ 02:01 リフレッシュトークンAで更新 🔄 │ 新しいアクセストークンB取得 ✅ │ ⚠ リフレッシュトークンAは無効化 │ 04:01 アクセストークンB期限切れ ❌ │ 04:02 リフレッシュトークンBで更新 🔄 │ 新しいアクセストークンC取得 ✅ │ ⚠ リフレッシュトークンBは無効化 │ ... この繰り返し(6ヶ月間有効) このタイムラインを見ると、リフレッシュトークンも一緒に更新されていることがわかりますよね。 なぜこんなに短いの？ 「2時間って短すぎない？」と思った方もいるかもしれませんね。実は、これには重要なセキュリティ上の理由があるんです。 理由 説明 セキュリティ トークンが盗まれても、2時間しか使えない 不正利用防止 盗まれたトークンの使用期間を制限し、被害を最小化 権限変更の反映 ユーザーがアプリ連携を解除した際、速やかに無効化される ラーメン屋の食券で例えると ： 食券の有効期限が短い → 盗まれても被害が少ない 毎回新しい食券をもらう → 古い食券は使えない セキュリティと利便性のバランス 短い有効期限のおかげで、セキュリティを保ちながらAPIを使えるというわけですね。 リフレッシュトークン：長期有効な会員カード リフレッシュトークンとは？ リフレッシュトークン は、アクセストークンが期限切れになった際に、 ユーザーに再認証させることなく 新しいアクセストークンを取得するための特別なトークンです。 前回の記事で解説したOAuth認証のログイン画面、あれを毎回表示するのは面倒ですよね。リフレッシュトークンがあれば、ユーザーに気づかれることなく、バックグラウンドで自動的にアクセストークンを更新できるんです。 これは非常に便利な機能ですね。 リフレッシュトークンの取得方法 リフレッシュトークンを取得するには、OAuth認証時に** offline.access **という特別なスコープ(権限)を指定する必要があります。 tweet.read : ツイートの読み取り tweet.write : ツイートの投稿 users.read : ユーザー情報の取得 offline.access : ← これがないとリフレッシュトークンが発行されない！ この offline.access を忘れると、リフレッシュトークンがもらえず、2時間ごとに再ログインが必要になってしまいます。これは実装時に注意すべきポイントですね。 有効期限：6ヶ月 トークン 有効期限 役割 アクセストークン 約2時間 API呼び出しに使用 リフレッシュトークン 約6ヶ月 アクセストークンの再取得に使用 リフレッシュトークンは約6ヶ月間有効なので、この期間中は自動的にアクセストークンを更新し続けることができます。 カフェの例で言うと ： ドリンクチケット(アクセストークン)は2時間で期限切れ 会員カード(リフレッシュトークン)は6ヶ月間有効 カードがあれば、いつでも新しいチケットがもらえる 便利ですよね。 リフレッシュトークンの「使い捨て」性質【最重要】 ここが今回の記事で最も重要なポイントです。多くの初心者がつまずく部分なので、カフェの比喩でじっくり理解していきましょう。 重要：リフレッシュトークンは使い捨て X APIのリフレッシュトークンには、とても重要な特徴があります。それは**「使い捨て(One-time use)」**であることです。 これは、他のOAuth実装とは異なる点もあるため、特に注意が必要ですね。 カード交換の仕組み カフェでの会員カード更新シーンを詳しく見てみましょう： ユーザ ドリンクチケットが期限切れになりました。 新しいチケットをください カフェ かしこまりました。会員カードを見せてください ユーザ 古い会員カードAを渡す カフェ (以下の3つを同時に実行) ① 新しいドリンクチケットを発行 ② 新しい会員カードBを発行 ③ 古い会員カードAをシュレッダーで破棄 ユーザ 新しい会員カードBと新しいドリンクチケットを受け取る 重要なポイント3つ 1. リフレッシュトークンは1回使ったら無効になる 会員カードAを使った瞬間、そのカードは二度と使えなくなります。まるでシュレッダーにかけられたかのように、完全に無効化されるんですね。 2. 新しいアクセストークンと新しいリフレッシュトークンの両方を取得 トークン更新時には、新しいドリンクチケット(アクセストークン)だけでなく、新しい会員カード(リフレッシュトークン)も一緒にもらえます。この 両方を保存する 必要があります。 3. 古いリフレッシュトークンは二度と使えない もし古い会員カードAをもう一度使おうとすると、「このカードは無効です」とエラーになります。 なぜこんな仕組みなの？ 「なんでこんな面倒なことするの？」と思った方もいるかもしれませんね。でも、これはセキュリティのための重要な仕組みなんです。 理由 説明 セキュリティ カードが盗まれても、すでに使用済みなら無効 不正検知 古いカードが使われたら「盗難された」と即座に判断できる 被害の最小化 盗まれたカードを使えないようにして、不正利用を防ぐ この仕組みのおかげで、セキュリティが大幅に向上しているんですね。 正常フローと攻撃シナリオ 正常フロー リフレッシュトークンAを使用 → 新しいアクセストークンB取得 → 新しいリフレッシュトークンB取得 → AはX APIによって無効化される リフレッシュトークンBを使用 → 新しいアクセストークンC取得 → 新しいリフレッシュトークンC取得 → BはX APIによって無効化される この繰り返しで6ヶ月間使える 攻撃シナリオ(使い捨て性質が守ってくれる) 攻撃者があなたの通信を盗聴 → リフレッシュトークンBをコピー あなたが正常にトークンBを使用 → 新しいトークンC/D取得 → Bは無効化される 攻撃者が盗んだトークンBを使おうとする → エラー「このトークンは無効です」 → X APIが不正アクセスを検知 → あなたに通知が届く 結果：攻撃者はAPIにアクセスできない！ カフェの例で言うと ： 会員カードが盗まれる でも、あなたがすでに新しいカードに交換済み 盗んだ人が古いカードを使おうとする 「このカードは無効です」と拒否される 店員が「不正利用の疑いあり」と気づく このように、リフレッシュトークンの「使い捨て性質」は、セキュリティを守るための重要な仕組みなんですね。 トークンの保存：2つの選択肢 トークンを取得したら、どこかに保存する必要がありますよね。保存方法は大きく分けて2つあります。 選択基準 どちらを選ぶかは、 実装するシステムの種類 によって変わります。 保存先 使うケース 特徴 クッキー ユーザーが今すぐ操作するアプリ シンプル、短期利用向け データベース バッチ処理・自動投稿システム 暗号化必須、長期利用向け 実際のプロジェクトでどちらを選ぶべきか、迷うところですよね。それぞれ詳しく見ていきましょう。 1. クッキーに保存(即時操作向け) どんな時に使う？ ユーザーが「今すぐ投稿したい」とボタンを押すようなアプリケーションの場合、クッキーに保存するのが適しています。 ユーザーが「投稿」ボタンをクリック クッキーからアクセストークンを取得 X APIで投稿実行 結果を画面に表示 メリット 処理がシンプル → クッキーの存在確認だけでOK → 有効期限の管理が自動 実装が簡単 → 複雑な暗号化処理が不要(HTTPOnly Cookieを使えば基本的に安全) デメリット ブラウザから参照可能 → 開発者ツールで見える → セキュリティリスクがある ブラウザを閉じたら消える可能性 → 有効期限設定次第 実装パターン フロント側で実装する場合、シンプルに作るなら アクセストークンだけ保存 しても大丈夫です。期限切れになったら、もう一度認証フローを実行してもらえばOK。 より高度に実装するなら、リフレッシュトークンも保存して自動更新することで、ユーザーにログイン画面を表示せずに済みますね。 カフェの例 ： クッキー = ポケットにチケットを入れる 手軽に使えるけど、落としたら危ない 短時間の利用に向いている 2. データベースに保存(バッチ処理向け) どんな時に使う？ 予約投稿や自動投稿など、ユーザーの操作とは別に定期実行するシステムの場合、データベースに保存する必要があります。 毎朝9時に自動投稿 予約した時間にツイート 定期的にフォロワー情報を取得 メリット 長期間保存できる → ブラウザを閉じても大丈夫 事前更新で確実性UP → リフレッシュトークンで事前に新しいアクセストークンを準備 → バッチ処理実行時にエラーが出ない デメリット セキュリティリスクが高い → データベースにアクセスできる人全員がトークンを見られる → 暗号化が必須 実装が複雑 → 暗号化・復号化の処理が必要 セキュリティ対策 データベースに保存する場合、 必ず暗号化 してから保存する必要がありますね。 環境変数に暗号化キーを保存 トークンを暗号化してからデータベースに保存 使用時に復号化してAPIに送信 もしそのまま保存してしまうと、データベースにアクセスできる人全員がトークンを見られてしまい、不正利用のリスクが高まります。これは避けたいところですね。 カフェの例 ： データベース = 金庫にチケットを保管 暗号化 = 金庫の鍵(誰も開けられない) 安全だけど、実装に手間がかかる どちらを選ぶべき？ ケース 保存方法 理由 即時投稿アプリ クッキー ユーザーが今すぐ使う 予約投稿システム データベース 後で自動実行する バッチ処理 データベース 常に有効なトークンを確保 システムの要件に合わせて、適切な保存方法を選びましょう。 よくある誤解・アンチパターン リフレッシュトークンの実装でよくある誤解を3つ紹介しますね。これらを避けることで、正しくトークン管理ができるようになります。 誤解1：リフレッシュトークンは何度も使える これは最も多い誤解です。私も最初はこう思っていました。 間違った理解 「会員カードは何度も使えるから、1回保存しておけばずっと使える」 正しい理解 「会員カードは1回使ったら新品に交換される。 古いカードは即座に破棄される」 何が起こるか ： 古いリフレッシュトークンを使い続けようとすると、2回目以降は「このトークンは無効です」というエラーが返ってきます。 カフェの例 ： 古い会員カードAを使う → 新カードBをもらう また古いカードAを使おうとする → 「このカードは無効です」と拒否される カードは1回限りの使い捨て！ 誤解2：アクセストークンだけ更新すればいい これもよくある実装ミスですね。 間違った実装 リフレッシュトークンAでアクセストークン更新 新しいアクセストークンBだけ保存 古いリフレッシュトークンAをそのまま保持 → 次回、Aを使おうとすると失敗！ 正しい実装 リフレッシュトークンAでアクセストークン更新 新しいアクセストークンB + 新しいリフレッシュトークンBの両方を保存 古いトークンAは破棄 → 次回、新しいBを使えば成功！ カフェの例 ： 新しいドリンクチケットだけもらって、古い会員カードを使い続けようとする 新しいドリンクチケットと新しい会員カードの両方をもらう 重要なポイント ： トークン更新時は、 両方のトークンを必ず保存 してください。これを忘れると、次回の更新で失敗しますね。 誤解3：トークンは永遠に有効 これもよくある勘違いです。 間違った理解 「一度認証すれば、ずっと使い続けられる」 正しい理解 「アクセストークン：2時間で期限切れ」 「リフレッシュトークン：6ヶ月で期限切れ」 → 6ヶ月後は再認証が必要 6ヶ月後はどうなる？ リフレッシュトークンも6ヶ月で期限切れになります。その場合は、ユーザーにもう一度OAuth認証画面からログインし直してもらう必要がありますね。 【6ヶ月後のタイムライン】 0日目 認証完了 ✅ ↓ 30日目 問題なく動作中 ✅ ↓ 180日目 リフレッシュトークン期限切れ ⚠ ↓ 181日目 「再度ログインしてください」と通知 ユーザーが再認証 新しいトークンセット取得 ✅ カフェの例 ： 会員カードにも有効期限がある(6ヶ月) 期限が切れたら、もう一度会員登録が必要 新しいカードをもらえば、また6ヶ月使える このように、トークンには必ず有効期限があることを理解しておきましょう。 まとめ お疲れ様でした！今回は、X APIのトークン管理について、カフェの会員システムの比喩で解説してきました。 今回学んだこと トピック ポイント アクセストークン 2時間有効、API呼び出しに使用する「ドリンクチケット」 リフレッシュトークン 6ヶ月有効、 使い捨て性質 がある「会員カード」 保存方法 クッキー(即時操作) vs データベース(バッチ処理) 最重要ポイント(再掲) リフレッシュトークンを使うときは、この3つを必ず覚えておいてくださいね： リフレッシュトークンは1回使ったら無効になる トークン更新時は、アクセストークンとリフレッシュトークンの両方が新しくなる 古いリフレッシュトークンは即座に無効化される → これがセキュリティの要 カフェの例で言えば ： 会員カードを使うと、新しいドリンクチケットと新しい会員カードの両方がもらえる 古い会員カードはシュレッダー行き これで盗難されても安心 関連記事 ふんわり始めるX API認証｜OAuth2.0とPKCEを初心者向けに図解解説 参考資料 X API Documentation OAuth 2.0 RFC 6749 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post X API OAuth 2.0トークン管理入門｜使い捨てリフレッシュトークンの仕組みを図解 first appeared on SIOS Tech. Lab .

この記事について 対象読者 : OAuth2.0という名前は聞いたことがあるけど、具体的にどうすればよいかわからない。でも、X API経由で投稿してみたい人 ゴール : OAuth2.0とPKCEの概念を理解して、実装に入る準備ができる X API OAuth2.0とPKCEの仕組みをラーメン屋の比喩でふんわり解説。認証コードフローからcode_verifierの安全な生成方法、CSRF対策まで初心者にもわかりやすく図解で紹介。実装前の概念理解に最適 はじめに ども!X APIを活用したアプリ開発をしている龍ちゃんです。最近、新卒エンジニア向けに技術研修の資料を作っていたんですが、やっぱり認証周りってちゃんと整理しないとダメだなと痛感しています。 この記事では、OAuth2.0について特に詳しくない方でも、X APIを実装できるようになるための基礎知識を解説しますね。ちゃんと理解したほうが良い概念ではありますが、まずは「ふんわり理解」から始めましょう。 しっかり勉強したい方は、以下の2冊がおすすめです: 雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本[2023年改訂版] OAuth、OAuth認証、OpenID Connectの違いを整理して理解できる本 [2024年改訂版] 弊社のブログであれば合わせて読むなら以下の連載がお勧めです！ 【連載】世界一わかりみの深いOAuth入門 〜 その1:OAuthってなに？ 〜 【連載】世界一わかりみの深いOAuth入門 〜 その2:アクセストークンとリフレッシュトークン 〜 【連載】世界一わかりみの深いOAuth入門 〜 その3:OAuthを認証に使うことの危険性 〜 【連載】世界一わかりみの深いOAuth入門 〜 その4:stateパラメーターによ る CSRF対策 〜 こちらの内容を活用して作成したアプリの記録は「 AIチャットで話すだけ!X予約投稿を完全自動化するシステム構築術 」で解説しています。 なぜOAuth2.0が必要なの? X APIを使ってツイートを投稿したり、情報を取得したりするには、 「このアプリは信頼できる」「このユーザーが許可している」ことを証明する必要があります 。 昔ながらの方法(ID/パスワード直接入力)の問題点 もしID/パスワードをアプリに直接入力する方式だと: アプリがパスワードを保存できてしまう パスワードが漏洩したら全てのサービスで不正利用される アプリに全権限を渡すことになる(投稿だけしたいのに、DM読み取りもできる) OAuth2.0を使うと パスワードを教えずに権限だけ渡せる 必要な権限だけを限定できる(投稿のみ、読み取りのみなど) いつでも権限を取り消せる まずは、X APIを使用するために必要な基本的な画面を見てみましょう。 X API OAuth2.0の認証画面 – SIOSTechLabアプリへのアクセス許可を求める画面のスクリーンショット このような画面を表示させてアカウント連携を行い、 トークン(アクセストークン・リフレッシュトークン)を取得します 。そのトークンを使用してX APIを実行するわけですね。 OAuth2.0をラーメン屋で例えると OAuth2.0の仕組みを理解するために、ラーメン屋で例えてみましょう。 登場人物 あなた : APIを使いたいユーザー(Resource Owner) アプリ : あなたが使うアプリケーション(Client) 券売機 : X の認証システム(認可サーバー / Authorization Server) ラーメン屋 : X APIサービス本体(リソースサーバー / Resource Server) 全体の流れ あなたは人気のラーメン屋(X)でラーメン(APIリソース)を食べたいです。でも、このラーメン屋は直接注文できません。専用アプリ経由でしか注文できないルールなんですね。 ステップ1: アプリで注文開始 「このアプリでラーメン食べたい!」とアプリに伝えます。 ステップ2: 券売機で申し込み(認可リクエスト) アプリが券売機(認可サーバー)に「このラーメンを注文したいです」と申請書を出します。 ステップ3: 本人確認(ログイン・認可) 券売機が「あなた本人ですか?」と確認します。顔認証(Xへのログイン)で本人確認を済ませますね。 ステップ4: 引換券をもらう(コールバック) 本人確認が完了すると、券売機から**一時的な引換券(認可コード: code)**をもらいます。 ステップ5: 引換券→食券に交換(トークンリクエスト) 引換券を持ってアプリが窓口に行き、**本物の食券(アクセストークン)**に交換します。 ステップ6: ラーメンゲット!(リソースアクセス) 食券を渡してラーメン(APIデータ)を受け取ります。 なぜこんなに面倒なの? もしID/パスワードを直接アプリに教える方式だと、悪意のあるアプリがパスワードを盗んで好き放題できてしまいますよね。 OAuth2.0なら: 「このアプリにラーメン注文の権限だけあげる」という 権限の制限 ができる パスワードをアプリに教えなくていい いつでも権限を取り消せる(食券を無効化できる) 必要なエンドポイント この仕組みを実装するには、最小で 2つのエンドポイント が必要です: 1. 認証URL発行エンドポイント 券売機への申請書を出すためのエンドポイントですね。ユーザーをX の認証画面にリダイレクトします。 2. コールバックエンドポイント 券売機から発行された引換券(code)を受け取るエンドポイント。このcodeを使ってアクセストークンを取得します。 OAuth2.0の詳細な流れ(シーケンス図) OAuth2.0認可コードフローのシーケンス図 – ユーザー、クライアントアプリ、認可サーバー、リソースサーバー間の通信フローを図解 各ステップの詳細 ステップ ざっくり理解 正確な流れ 2. 認可リクエスト 認可リクエストのURLをください 認可の開始: クライアントがユーザーを認可サーバー(AS)へ誘導し、「この**権限(Scope)**を借りたい」とASに伝える 3〜4. ログイン・認可 その用途で使用することに合意します。本人確認は行いました 権限の付与: ユーザーがAS上でログインし、クライアントアプリが要求した権限(Scope)の付与を許可する 5. コールバック 本人確認了承しました。きちんと処理が行われていますね 認可コードの受け渡し: ASがクライアントアプリのコールバックURLに 認可コード(code)とstate を渡す。これは一時的で、まだサービスにアクセスするためのキーではない 6〜9. トークンリクエスト 具体的にサービスにアクセスするためにキーの取得を行いますね トークンへの交換: クライアントがASに対し、受け取った code を提示して、サービスアクセス用の本物のキーである アクセストークン との交換を要求する 10. リソースリクエスト キーを使ってサービスにアクセスを行います リソースへのアクセス: 取得した アクセストークン を提示して、リソースサーバー(RS)に保護された情報(リソース)へのアクセスを要求する X APIで必要な重要パラメータ 1. Scope(スコープ): 「何ができる権限か」 ラーメンの例で言うと「ラーメンだけ注文できる券」なのか「ラーメン+餃子まで注文できる券」なのか、という 権限の範囲 ですね。 X APIでよく使うScope Scope 説明 tweet.read ツイートを読む権限 tweet.write ツイートを投稿する権限 users.read ユーザー情報を読む権限 follows.read フォロー情報を読む権限 follows.write フォロー/アンフォローする権限 重要 : 必要な権限だけを要求するのがセキュリティ上重要です。投稿だけしたいのに全権限を要求すると、ユーザーに警戒されちゃいますよね。 2. redirect_uri(リダイレクトURI): 「引換券を受け取る住所」 認可サーバーが「引換券(code)をどこに送ればいいの?」を指定するのがredirect_uriです。 重要なポイント X Developer Portalで事前に登録したURLと 完全一致 する必要がある 末尾の / まで含めて一致させる 本番環境: https://yourdomain.com/callback 開発環境: http://localhost:3000/callback (ローカル開発用) よくあるエラー ❌ Developer Portalに登録: <https://example.com/callback> ❌ コードで指定: <https://example.com/callback/> → 末尾のスラッシュが違うのでエラー! ✅ Developer Portalに登録: <https://example.com/callback> ✅ コードで指定: <https://example.com/callback> → 完全一致でOK! 3. state: 「偽造防止のおまじない」 CSRF攻撃を防ぐためのランダムな文字列です。認可リクエストで送ったstateと、コールバックで返ってきたstateが一致するか確認します。 ラーメンの例で言うと「整理番号」のようなものですね。自分の整理番号と違う引換券が返ってきたら怪しいですよね。 // state生成の例 const state = crypto.randomUUID(); // "550e8400-e29b-41d4-a716-446655440000" sessionStorage.setItem('oauth_state', state); // コールバックで確認 const returnedState = new URLSearchParams(window.location.search).get('state'); const savedState = sessionStorage.getItem('oauth_state'); if (returnedState !== savedState) { throw new Error('State不一致！CSRF攻撃の可能性あり'); } PKCEが必要な理由 さて、ここまでの仕組みでも一応動きますが、実は セキュリティリスク があります。 認可コード(code)が盗まれたら? もし通信途中でcodeが盗聴・盗難された場合、以下のような攻撃が可能になります: OAuth2.0認可コード横取り攻撃のシーケンス図 – PKCEなしの場合に攻撃者が認可コードを盗聴するリスクを図解 具体的には: 正規のクライアントアプリで認可リクエストを送る 通信途中で攻撃者がcodeを盗聴 攻撃者が盗んだcodeを使ってトークンリクエストを送る 認可サーバーは正しいcodeなのでトークンを発行してしまう 攻撃者がユーザーのリソースにアクセスできてしまう ラーメン屋で例えると PKCEなしの場合(危険!) : 券売機で引換券だけもらう 引換券を持って窓口に行けば食券がもらえる → 途中で引換券を盗まれたら、誰でも食券に交換できちゃう! PKCEありの場合(安全!) : 券売機で注文する時に「愛言葉」を決める 券売機には「愛言葉のヒント」だけ伝える 引換券をもらう 窓口で引換券と「愛言葉の本物」を見せる 店員が「ヒントと愛言葉が一致するか」確認してから食券を渡す → 引換券を途中で盗まれても、愛言葉がないと食券には交換できない! PKCEの仕組み PKCE(Proof Key for Code Exchange)は、 認可リクエストしたクライアントとトークンリクエストを行ってきたクライアントが同一であることを証明 するための仕組みです。 主要な登場人物 用語 説明 ラーメンの例 code_verifier あなただけが知っている秘密の文字列 愛言葉の本物 code_challenge code_verifierをハッシュ化したもの 愛言葉のヒント PKCEの流れ 事前準備 : クライアントアプリがcode_verifier(秘密の文字列)を生成 認可リクエスト : code_challenge(ハッシュ化したもの)を送信 コールバック : codeを受け取る トークンリクエスト : codeと一緒にcode_verifier(元の文字列)を送信 検証 : 認可サーバーがcode_verifierをハッシュ化して、最初のcode_challengeと一致するか確認 code_verifierのよくある誤解 危険な実装:固定の愛言葉を使い回す code_verifierを 固定文字列や予測可能な値にしてしまう のは、とても危険な実装です。 // ❌ 危険な例:固定文字列 const code_verifier = "my_secret_verifier_2024"; これでは、PKCEの意味がなくなってしまいます。 ラーメン屋で例えると 悪い例 : 店員:「愛言葉は?」 あなた:「いつも『ラーメン大好き』って決めてるんだ!」 盗聴者:「次回も『ラーメン大好き』って言えば食券もらえるな…」 良い例 : 店員:「愛言葉は?」 あなた:「今回は『X7mK9pQ2vR8nL3zA』!」(毎回ランダムに自動生成) 盗聴者:「今回の愛言葉聞いたけど、次は全然違うやつ使ってる…予測できん!」 正しい実装:機械的にランダム生成 code_verifierは必ず暗号学的に安全な方法で、毎回ランダムに生成する必要があります。 // ✅ 良い例:毎回異なる、予測不可能な愛言葉を生成 function generateCodeVerifier() { const array = new Uint8Array(32); // 32バイトのランダムデータ crypto.getRandomValues(array); // 暗号学的に安全な乱数 return base64UrlEncode(array); // URL安全な文字列に変換 } const code_verifier = generateCodeVerifier(); // 例: "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk" なぜ機械的に生成するの? 理由 説明 人間は弱い 人が考える「ランダム」は実はパターンがある(誕生日、好きな言葉など) 十分な長さ 推奨は43〜128文字。短いと総当たりで破られる 毎回違う 同じ愛言葉の使い回しを防ぐ 予測不可能 暗号学的に安全な乱数生成器( crypto.getRandomValues )を使う X APIでの推奨仕様 OAuth2.0/PKCEの仕様(RFC 7636)では: 長さ : 43〜128文字 文字種 : A-Z , a-z , 0-9 , , . , _ , ~ (Base64URL) 生成方法 : 暗号学的に安全な乱数生成器 code_challengeの計算方法 愛言葉(code_verifier)から、ヒント(code_challenge)を作ります。これはSHA-256ハッシュ関数を使って計算しますね。 ポイント 一方向性 : code_challengeからcode_verifierを逆算することは 不可能 (ハッシュ関数の一方向性) 検証方法 : 認可サーバーは「受け取ったcode_verifierをハッシュ化したら、最初のcode_challengeと一致するか」だけ確認できる セキュリティまとめ 攻撃者の視点で考える 引換券(code)を盗聴した! → でも愛言葉(code_verifier)がわからないから食券に交換できない ヒント(code_challenge)は見えてる! → でもハッシュ化されてるから、元の愛言葉は逆算できない 前回の愛言葉を盗聴した! → 毎回ランダムに変わるから、次回は使えない よくある実装ミス code_verifier編 // ❌ ダメな例1:固定文字列 const code_verifier = "my_app_verifier"; // ❌ ダメな例2:短すぎる const code_verifier = Math.random().toString(36).substring(7); // 7文字程度 // ❌ ダメな例3:予測可能 const code_verifier = `verifier_${Date.now()}`; // タイムスタンプは予測可能 // ❌ ダメな例4:弱い乱数 const code_verifier = Math.random().toString(36); // Math.random()は暗号学的に安全ではない // ✅ 良い例:暗号学的に安全なランダム生成 const code_verifier = generateCodeVerifier(); // 前述の関数 redirect_uri編 // ❌ ダメな例:末尾のスラッシュが不一致 // Developer Portal登録: https://example.com/callback const redirect_uri = "https://example.com/callback/"; // 末尾に / あり // ✅ 良い例:完全一致 const redirect_uri = "https://example.com/callback"; state編 // ❌ ダメな例:stateの検証を忘れる const code = new URLSearchParams(window.location.search).get('code'); // stateの確認をしていない! // ✅ 良い例:stateを検証 const returnedState = new URLSearchParams(window.location.search).get('state'); const savedState = sessionStorage.getItem('oauth_state'); if (returnedState !== savedState) { throw new Error('State不一致！CSRF攻撃の可能性あり'); } X API での具体的な設定 Developer Portalで設定すること Appの作成 https://developer.x.com/en/portal/dashboard にアクセス 新しいAppを作成 OAuth 2.0の有効化 App設定画面で「User authentication settings」を編集 OAuth 2.0を有効にする Callback URLの登録 開発環境（Ngrok必要！）: http://localhost:3000/callback 本番環境: https://yourdomain.com/callback 重要 : 末尾のスラッシュまで含めて正確に登録 Permissionsの設定 Read: ツイート読み取りのみ Read and Write: ツイート読み取り+投稿 Read and Write and Direct Messages: DM含む全権限 まとめ この記事で学んだこと OAuth2.0の必要性 : パスワードを教えずに権限だけ渡せる仕組み 全体の流れ : ラーメン屋の例で理解する認可フロー PKCEの重要性 : codeの盗聴・盗難を防ぐ仕組み code_verifierの生成 : 機械的にランダム生成することの重要性 重要パラメータ : scope, redirect_uri, stateの役割 実装時の注意点 code_verifierは毎回ランダム生成(43文字以上) 暗号学的に安全な乱数生成器を使用 redirect_uriは完全一致させる stateでCSRF対策 必要最小限のscopeを要求 次のステップ この記事でOAuth2.0とPKCEの概念は理解できました!次は実際に実装してみましょう: X Developer Portalでアプリを作成 認証URL発行エンドポイントの実装 コールバックエンドポイントの実装 トークンを使ってAPI実行 実装編の記事もお楽しみに! 参考資料 推奨書籍 雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本[2023年改訂版] OAuth、OAuth認証、OpenID Connectの違いを整理して理解できる本 [2024年改訂版] 公式ドキュメント X API Documentation OAuth 2.0 RFC 6749 PKCE RFC 7636 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post ふんわり始めるX API認証｜OAuth2.0とPKCEを初心者向けに図解解説 first appeared on SIOS Tech. Lab .

はじめに ども!9月から開発していたシステムがようやく稼働・運用できるようになって、ひと段落した龍ちゃんです。コツコツ開発していたものがやっと形になったので一安心ですね。 今回完成したのは、以前の記事「 Claude API×GitHub Actions完全自動化でコスト60%削減!ブログ投稿システム構築術 」で紹介したブログ宣伝システムの 続編 となるシステムです。前回はブログURLから投稿文を自動生成してデータベースに保存する仕組みを作りましたが、今回はそのデータを使って、 X（Twitter）への予約投稿を完全自動化 しました。 僕はですね、社内でX投稿の担当をしていまして…毎日の投稿予約作業が地味に大変だったんですよね。コピペして、予約画面開いて、日時設定して…の繰り返し。これ、なんとか楽にならないかなぁと思っていたわけです。 そこで作ったのが、 AIチャットで話しかけるだけで予約投稿が完結するシステム です! 皆さんも、X投稿の運用で似たような悩み、ありませんか? こんな悩み、ありませんか? 皆さん、X投稿の運用って、地味に大変じゃないですか？ 私の場合、1日3件投稿できればいい方でした。投稿内容は自動的に生成されるようになっているのですが、以下の手順での「手動投稿作業」での「3件」がけっこう曲者でして… 手動予約の現実 Xを開く 投稿文をコピペ 予約画面を開く 日時を設定 投稿ボタンをクリック これで1件です。目安にして、1件の予約に 5〜6回のボタン操作 が必要なんですよね。 1日3件なら、単純計算で 15回以上のボタン操作 。毎日やるとなると…めんどくさい! そして何より困るのが、 気づいたら忘れてる こと。仕事に集中してコード書いてたら、1週間まるっと投稿してない、なんてこともありました。コード書いてる方が楽しいし、ついつい投稿作業を後回しにしちゃうんですよね（笑） さらに、ブログ記事がどんどん増えていくので、宣伝したい内容も増える一方。気づいたら「あれ、このブログまだ宣伝してない!」なんてことも。 まとめて1週間分を予約できればいいんですけど、単純作業の繰り返しは地味にストレスなんですよね… 解決策 – AIチャットで完結する予約投稿システム そこで作ったのが、 AIチャットで話しかけるだけで予約投稿が完結するシステム です! ビフォー・アフター Before 龍ちゃん手動 GitHubで投稿文ファイルを探す（2分） 投稿文をコピー Xを開く コピペして予約画面へ 日時を設定して投稿 ↓ 1件あたり約2分 × 10件 = 約20分 After AIチャット 「明日の昼にAIカテゴリから10件予約して」 とチャットに入力 ↓ 約10秒で完了! 削減できた時間 : 20分 → 10秒（ 98%の時短 ） システムの核心機能 このシステムの最大の特徴は、 自然言語で指示するだけ という手軽さです。 「明日の昼に」 → 自動的に日時を計算 「AIカテゴリから」 → データベースを検索 「3件予約して」 → 一括で予約作成 GitHubを開く必要も、Xの予約画面を操作する必要もありません。チャットで指示を出せば、あとはAIが全部やってくれます。 実際の使い方を見てみよう 百聞は一見にしかず! 実際のチャットのやり取りを見てみましょう。実際のアプリのデモを録画しました。内容的に丁寧にレコーディングしたので、デモとしては若干長めですが、実際の使い勝手がよくわかると思います。 使用例: 1週間分をまとめて予約 下記はイメージになります。 龍ちゃん AIカテゴリからランダムに10件取得して、 明日から順番に連続で登録してください AIチャット ✓ カテゴリ「AI」で検索しました ✓ 投稿候補を10件見つけました 【投稿候補】 ChatGPTの新機能を試してみた（パターンA） プロンプトエンジニアリング入門（パターンB） AIで業務効率化した事例（パターンA） Claude Codeの実践活用術（パターンC） GitHub Copilotのベストプラクティス（パターンA） …（以下5件） これらを明日から順番に予約しますか? 龍ちゃん はい、朝9:00から順番に登録してください AIチャット ✓ 予約を作成しました! 【予約完了】 1/28（火） 9:00 ChatGPTの新機能を試してみた 1/29（水） 9:00 プロンプトエンジニアリング入門 1/30（木） 9:00 AIで業務効率化した事例 1/31（金） 9:00 Claude Codeの実践活用術 2/1（土） 9:00 GitHub Copilotのベストプラクティス …（以下5件） 週間カレンダーで確認できます! ポイント: 対話しながら調整できる このシステムの良いところは、 AIと対話しながら調整できる こと。普通のチャット感覚で指示できるので、操作に迷うことがありません。 パターン1: 未投稿記事だけを選ぶ あなた: 「直近投稿したやつ以外で、AIカテゴリから5件」 AI: 「未投稿の記事を5件抽出しました」 パターン2: 投稿パターンを変える あなた: 「この記事、パターンBで投稿したい」 AI: 「パターンBに変更しました」 パターン3: カテゴリ・ハッシュタグを統合する あなた: 「"AI開発"カテゴリと"AI"カテゴリを統合して」 AI: 「カテゴリを統合しました。今後は"AI"に統一されます」 主な機能 このシステムには、X投稿を楽にするための機能がいろいろと詰まっています。 カテゴリ・ハッシュタグで検索 ブログ記事は自動的にカテゴリとハッシュタグで整理されています。「AIカテゴリから」「#初心者向け のハッシュタグで」など、自然な言葉で検索できるんです。 重複したカテゴリやハッシュタグも、チャット上で統合・整理できるので、運用しながら綺麗に管理できるのも嬉しいポイントですね。 自然言語で日時指定 「明日の昼」「来週月曜の朝」「今日から3日連続で」など、自然な表現で日時を指定できます。AIが自動的に正確な日時に変換してくれます。 投稿時間は、 1日4回の固定時間 （9:00／12:00／15:00／21:00）から選べます。読まれやすい時間帯を考慮した設定です。 週間カレンダーで予約確認・自動投稿 予約した投稿は、週間カレンダーで一覧表示されます。いつ、どの記事が投稿されるのか、一目で確認できます。 予約した日時になると、自動的にXに投稿されます。投稿の成功・失敗も記録されるので、安心して任せられます。 投稿パターンの選択 各ブログ記事には、3パターン（A／B／C）の投稿文が事前にデータベースに保存されています。同じ記事でも、違う表現で複数回投稿できます。 （投稿文の生成方法については 前回の記事 で解説しています） 導入効果 10月初旬から本格運用を開始して、約半月が経過しました。すでに 約50件の投稿 をこのシステムで自動化しています。 数値で見る効果 以前は月に50件ペースで投稿していました。手動運用だと、この量は正直かなりキツかったんです… 時間削減効果 1件あたりの作業時間 : 2分 → 0秒 10件の予約作業 : 約20分 → 約10秒（ 98%削減 ） 月間削減時間 : 約100分（1時間40分） 年間削減時間 : 約20時間（ まる1日分の作業時間削減! ） 継続性の向上 手動運用時代は、忙しいときに1週間まるっと忘れることもありました。でも今は、 月曜日に1週間分をまとめて予約 しておけば、あとは自動で投稿されるので投稿忘れがゼロになりました。 体感としての効果 数値以上に大きいのが、 精神的な負担の軽減 です。 「今日の投稿、まだやってない…」というプレッシャーから解放されました。コード書いている時も、「投稿作業しなきゃ」と気にする必要がなくなったんです。 データベースに保存されている記事は、チャットで指示するだけで楽に登録できるので、 投稿運用のストレスがほぼゼロ になりました。 今の課題は「投稿内容をどう増やすか」に移行しています。つまり、 投稿作業そのものは完全に解決した ということですね! こんな人におすすめ このシステムは、以下のような方に特におすすめです: ブロガー・コンテンツクリエイター : ブログ記事の執筆に集中したい。投稿作業は自動化したい SNS担当者 : 定期的な投稿でブランド認知を高めたいが、手動運用は大変 エンジニア・技術ブロガー : 技術で課題を解決したい。自動化に興味がある 特に「 投稿作業に時間を取られるより、コンテンツ作成に集中したい 」という方にピッタリです! システムの裏側（ざっくり技術紹介） ここからは、このシステムがどんな技術で動いているのか、ざっくりと紹介します。 システム全体の構成 このシステムは、すべて Azure上 で構築されています。 シンプルな構成ですが、それぞれにこれまでの学びや工夫が詰まっています。 リソース名 役割 リンク Azure Static Web Apps Next.js 15フロントエンドのホスティング。週間カレンダーUIと投稿予約画面を提供。 https://learn.microsoft.com/azure/static-web-apps/ Azure Web App NestJS 11 APIバックエンド。AIチャット処理、X API連携、予約管理を担当。 https://learn.microsoft.com/azure/app-service/ Azure Functions Timer Triggerで6時間ごとに起動し、予約投稿を自動実行。 https://learn.microsoft.com/azure/azure-functions/ Azure OpenAI Service Function Callingで自然言語からの指示を理解し、適切な処理を実行。 https://learn.microsoft.com/azure/ai-services/openai/ Azure Key Vault Xのクライアントキー・Firebase認証情報などのシークレットを安全に管理。 https://learn.microsoft.com/azure/key-vault/ Firestore ブログ記事データ、投稿文パターン、予約情報を保存。暗号化されたX認証トークンも管理。 https://firebase.google.com/docs/firestore 1. AIチャット機能 – Function Calling チャットで自然言語の指示を理解できるのは、 Azure OpenAI ServiceのFunction Calling を活用しているからです。 26個の関数を用意して、「カテゴリで検索」「予約作成」「日時計算」などの処理を自動的に選択・実行してくれます。NestJSのDI（依存性注入）でうまく管理しているのがポイントです。 → 詳細は「NestJSで実現するAI Function Calling」で解説予定! 2. OAuth認証とセキュリティ Xに投稿するには、OAuth認証が必要です。取得した認証トークンをそのままデータベースに保存するのは危険なので、 暗号化・復号化の仕組み を実装しています。 データベースには暗号化された文字列だけが保存され、使用時に環境変数を使って復号化します。 ふんわり始めるX API認証｜OAuth2.0とPKCEを初心者向けに図解解説 X API OAuth 2.0トークン管理入門｜使い捨てリフレッシュトークンの仕組みを図解 → 詳細は「X OAuth認証とトークン暗号化」で解説予定! 3. 予約投稿の自動実行 X APIには予約投稿機能がありません（ここは！ちょっと文句がある！！）。そこで、 Azure FunctionsのTimer Trigger を活用しました。 1日4回（9:00／12:00／15:00／21:00）に定期的に起動し、データベースに予約があればX APIを実行する仕組みです。タイムゾーン処理やパフォーマンス最適化にも工夫があります。 → 詳細は「Azure FunctionsでX予約投稿を実現」で解説予定! 4. インフラ管理 AzureリソースはすべてBicepテンプレートで管理しています。APIキーやシークレットはAzure Key Vaultで安全に管理。 必要なAPIキーを登録すれば、 すぐに同じ環境を構築できる ようになっています。 X APIの制約を技術で解決 一番の技術的な見どころは、 「X APIに予約投稿機能がない」という制約をTimer Triggerで解決した 点です。 制約があるからこそ、工夫のしがいがありますよね。この辺りの実装テクニックは、技術解説シリーズで詳しく紹介していきます! AIと共に開発する ちなみに、このシステムの開発には Claude Code を活用しました。AIとペアプログラミングをしながら開発を進めることで、短期間で効率的にシステムを構築できました。 仕様を決めるのは人間、実装はAIに任せる——この役割分担がうまく機能したプロジェクトです。 まとめ AIチャットで完結するX予約投稿システムを作ったことで、以下を実現しました: 時間削減 : 月間約100分の作業時間削減（年間20時間） 簡単操作 : 自然言語で指示するだけ、わずか10秒で予約完了 完全自動化 : 予約した日時に自動投稿、投稿忘れゼロ 精神的負担軽減 : 「投稿しなきゃ」のプレッシャーから解放 これまで20分かかっていた予約作業が、わずか10秒に短縮されました。 次回以降の技術解説シリーズ 今回は「何ができるか」に焦点を当てましたが、今後は 技術的な実装詳細 を解説していきます! X OAuth認証とトークン暗号化 OAuth 2.0フロー Firebaseでの暗号化保存 Azure FunctionsでX予約投稿を実現 Timer Triggerの活用 タイムゾーン処理 パフォーマンス最適化 NestJSで実現するAI Function Calling 26関数の管理手法 NestJSのDI活用 SSEストリーミング実装 Azure FunctionsでMCP Serverを構築 MCP Tools実装 Experimental Bundle Supabase連携 各記事で、実際のコード例とともに詳しく解説していきます。 さいごに X投稿の自動化は、自分の作業を楽にするために始めたプロジェクトでしたが、結果的に大幅な時間削減と精神的負担の軽減につながりました。 単純作業はAIに任せて、人間は創造的な仕事に集中する —— これが理想的な働き方だと思います。AIと共に開発することで、より短期間で、より質の高いシステムを作れる時代になりました。 人間は贅沢なもので、だんだん面倒になるもののハードルが上がっていきます。こちらの運用から発展して、Xの運用そのものを完全に自動化することを検討しだしました。 ブログやコンテンツを定期的に発信している方は、ぜひ参考にしてみてください! このシステムについて質問や「こんな機能ほしい!」などのご意見があれば、ぜひコメント欄で教えてください。基本的にはマーケのお姉さんがクライアントとして、実装を頑張っています！技術詳細記事でコード例も公開予定です。 * 次回からの技術解説シリーズもお楽しみに! 参考リンク・公式リファレンス Azure関連 Azure OpenAI Service : 公式ドキュメント Azure Functions Timer Trigger : 公式リファレンス Azure Key Vault : 公式ドキュメント Bicep（Azure IaC） : 公式ドキュメント X（Twitter）API関連 X API v2 : 公式ドキュメント OAuth 2.0 認証 : 公式ガイド Post Tweet API : APIリファレンス フレームワーク・ライブラリ関連 NestJS : 公式ドキュメント Firebase : 公式ドキュメント Supabase : 公式ドキュメント ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post AIチャットで話すだけ!X予約投稿を完全自動化するシステム構築術 first appeared on SIOS Tech. Lab .

はじめに：なぜDevContainerとuvの組み合わせなのか ども！新卒のスムーズな開発のために環境を作っていたりする龍ちゃんです。直近でPythonのDevContainer環境を作る機会がありまして、 今までpipで環境を作っていました 。どうせなら、モダンな環境で作り直して渡そうと考えていました。モダンなPython開発環境に求められる要素は何でしょうか？ 再現可能な環境 : チーム全員が同じ環境で開発できる 高速なパッケージ管理 : ストレスのない依存関係のインストール 拡張性 : 必要に応じてツールを追加できる柔軟性 本記事では、DevContainerとuvを使った高速で再現可能なPython開発環境の構築方法を、ステップバイステップで解説します。 使用する技術スタック DevContainer : VS Codeの開発コンテナ機能 uv : Rustで実装された高速Pythonパッケージマネージャー（pipの10-100倍速） Microsoft公式イメージ : 安定性と互換性が保証された基盤 DevContainer + uv環境の全体構成 今回構築する環境のディレクトリ構成は以下の通りです： project-root/ ├── .devcontainer/ │ ├── Dockerfile # Python + Node.js環境の定義 │ ├── compose.yml # Dockerコンテナの設定 │ └── devcontainer.json # VS Code DevContainer設定 ├── pyproject.toml # Pythonプロジェクト設定 ├── src/ # ソースコード └── tests/ # テストコード ステップ1: Microsoft公式イメージベースのDockerfile Python環境にuvを追加したシンプルなDockerfileを作成します。 # .devcontainer/Dockerfile # Microsoft公式のPython DevContainerイメージを使用 FROM mcr.microsoft.com/devcontainers/python:3.11 # 追加ツール（必要に応じて） USER vscode RUN curl -LsSf https://astral.sh/uv/install.sh | sh ENV PATH="/home/vscode/.local/bin:${PATH}" # 作業ディレクトリの設定 WORKDIR /home/vscode/python # コンテナを起動したままにする CMD ["sleep", "infinity"] ポイント: Microsoft公式イメージで安定性を担保 非rootユーザー（vscode）で安全に実行 uv事前インストールで初回から高速セットアップ ステップ2: Docker Composeでコンテナ定義 # .devcontainer/compose.yml services: python: build: context: . dockerfile: ./Dockerfile tty: true volumes: - type: bind source: ../ target: /home/vscode/python restart: unless-stopped # ports: # - "8000:8000" # FastAPI等のWebアプリ用 ポイント: 単一サービス構成でシンプル ボリュームマウントでホストと同期 ステップ3: DevContainer設定 // .devcontainer/devcontainer.json { "name": "uv-python", "service": "python", "dockerComposeFile": "./compose.yml", "workspaceFolder": "/home/vscode/python", "customizations": { "vscode": { "extensions": [ "ms-python.python", "ms-python.vscode-pylance", "ms-python.black-formatter" ], "settings": { "python.defaultInterpreterPath": "/home/vscode/python/.venv/bin/python", "python.testing.pytestEnabled": true, "python.testing.pytestArgs": ["-q"], "editor.formatOnSave": true, "python.formatting.provider": "black" } } } } ステップ4: VS CodeでDevContainerを起動して開発開始 1. プロジェクトをDevContainerで開く VS Codeでプロジェクトディレクトリを開く コマンドパレット（ Cmd/Ctrl + Shift + P ）を開く 「Dev Containers: Reopen in Container」 を選択 初回起動時はDockerイメージのビルドに数分かかります コンテナが起動すると、VS Codeのウィンドウ左下に「Dev Container: uv-python」と表示されます。 2. ターミナルを開いて確認 VS Codeのターミナルを開き、環境を確認します。 # Pythonのバージョン確認 python --version # uvが利用可能か確認 uv --version # 作業ディレクトリの確認 pwd # /home/vscode/python が表示されるはず ステップ5: uvでプロジェクト初期化 # プロジェクトの初期化（pyproject.toml生成） uv init # 仮想環境の作成と有効化 uv venv source .venv/bin/activate # 依存関係の追加 uv add fastapi uvicorn pydantic uv add --dev pytest black flake8 mypy httpx # 反映 uv sync --all-groups pyproject.tomlの例 [project] name = "python" version = "0.1.0" description = "Add your description here" readme = "README.md" requires-python = ">=3.11" dependencies = [ "fastapi>=0.120.1", "pydantic>=2.12.3", "uvicorn>=0.38.0", ] [dependency-groups] dev = [ "black>=25.9.0", "flake8>=7.3.0", "httpx>=0.28.1", "mypy>=1.18.2", "pytest>=8.4.2", ] [tool.black] line-length = 100 target-version = ['py311'] [tool.mypy] python_version = "3.11" strict = true ignore_missing_imports = true [tool.flake8] max-line-length = 100 extend-ignore = ["E203", "W503"] [tool.pytest.ini_options] 注意 : [dependency-groups] は比較的新しい機能です。古いツールとの互換性が必要な場合は、代わりに [project.optional-dependencies] を使用することもできますが、uvを使う場合は [dependency-groups] の使用が推奨されます。 セットアップの確認 最後に、セットアップが正しく完了したことを確認します。 # インストールされたパッケージの確認 uv pip list # Blackでフォーマットが動作するか確認 black --version # mypyで型チェックが動作するか確認 mypy --version # pytestが動作するか確認 pytest --version 動作確認：DevContainerでFastAPIアプリを構築 簡単なアプリケーションの作成 セットアップが完了したら、実際にコードを書いて動作確認してみましょう。 # src/main.py from fastapi import FastAPI app = FastAPI() @app.get("/") def read_root(): return {"message": "Hello, uv DevContainer!"} @app.get("/items/{item_id}") def read_item(item_id: int): return {"item_id": item_id} アプリケーションの実行 # FastAPIアプリケーションの起動 uvicorn src.main:app --reload --host 0.0.0.0 --port 8000 ブラウザで http://localhost:8000 にアクセスすると、動作確認できます。 フォーマットとLintの実行 保存時の自動フォーマットに加えて、手動でも実行できます。 # Blackでコードをフォーマット black src/ # Flake8でLintチェック flake8 src/ # mypyで型チェック mypy src/ # すべてをまとめて実行 black src/ && flake8 src/ && mypy src/ テストの作成と実行 # tests/test_main.py from fastapi.testclient import TestClient from src.main import app client = TestClient(app) def test_read_root(): response = client.get("/") assert response.status_code == 200 assert response.json() == {"message": "Hello, uv DevContainer!"} # テストの実行 uv run pytest # カバレッジ付きでテスト実行 uv run pytest --cov=src tests/ uvコマンドのクイックリファレンス 開発中によく使うuvコマンドをまとめました。 # パッケージの追加 uv add requests # 通常の依存関係 uv add --dev pytest-cov # 開発用依存関係 # パッケージの削除 uv remove requests # パッケージの削除 # 依存関係の更新 uv lock # ロックファイルの更新 uv sync # 依存関係の同期 # pip互換コマンド uv pip install requests # pipコマンドと同じように使える uv pip list # インストール済みパッケージ一覧 uv pip freeze # requirements.txt形式で出力 # 仮想環境の管理 uv venv # 仮想環境の作成 uv venv .venv --python 3.11 # Pythonバージョン指定 # requirements.txtとの連携 uv pip install -r requirements.txt # requirements.txtからインストール uv pip freeze > requirements.txt # requirements.txtの生成 DevContainer + uv環境でよくあるエラーと解決法 問題1: uvコマンドが見つからない # PATHを確認 echo $PATH # PATHに追加（必要な場合） export PATH="$HOME/.local/bin:$PATH" echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc source ~/.bashrc # uvの再インストール curl -LsSf https://astral.sh/uv/install.sh | sh 問題2: Pythonインタープリターが認識されない VS Codeのコマンドパレットから 「Python: Select Interpreter」 を選択し、 /home/vscode/python/.venv/bin/python を指定します。 または、devcontainer.jsonで指定されているパスを確認： "python.defaultInterpreterPath": "/home/vscode/python/.venv/bin/python" 問題3: パーミッションエラーが発生する # 現在のユーザーを確認 whoami # vscode であることを確認 # ディレクトリの所有者を確認 ls -la /home/vscode/python # 必要に応じて権限を修正 sudo chown -R vscode:vscode /home/vscode/python 問題4: pytestがsrcをモジュールとして認識せず import に失敗する 症状: from src.main import app で ModuleNotFoundError などの収集時エラー 原因: Python パスにプロジェクトルート（ . ）が含まれず、 src がモジュール解決できない 対処: pyproject.toml に Python パスを付与（推奨） [tool.pytest.ini_options] pythonpath = ["."] 併用可: src/__init__.py を追加（空でOK） 検証: uv run pytest -q が成功すること。 python -c "import sys; print(sys.path[0])" でルートが入っていることを確認 まとめ 今回は、DevContainerとuvを組み合わせた爆速Python開発環境の構築方法を見てきました。 この環境で得られる3つのメリット 圧倒的な速度 : uvによってpipの10-100倍速でパッケージ管理 完全な再現性 : Dockerでチーム全員が同じ環境を共有 VS Code統合 : 拡張機能やデバッグがそのまま使える 特に、「ローカル環境を汚したくない」「チーム開発で環境差異に悩んでいる」という方には、ぜひ試していただきたいセットアップです。 実際にこの環境を使うことで、環境構築のストレスから解放され、コーディングに集中できるようになります。セットアップは最初の1回だけ。あとはチーム全員が同じ環境で快適に開発できますよ。 皆さんも、ぜひDevContainer × uv環境でPython開発にチャレンジしてみてください！質問や感想は、コメント欄でお待ちしております。 もしこの環境でNodeを使いたい（Claude CodeやCodexなどのnpmでインストールする系のツール）を使う場合は、こちらを参考にしてください。 参考リンク uv公式ドキュメント Microsoft DevContainers DevContainers仕様 VS Code DevContainers拡張機能 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post DevContainerとuvで構築する爆速Python開発環境｜VS Codeセットアップ手順 first appeared on SIOS Tech. Lab .

はじめに こんにちは、サイオステクノロジーの小沼 俊治です。 今回は、AIを活用した RAG アプリケーションの仕組みを無料で体験できるハンズオン環境 を用意しました。 このハンズオンでは、 LangChain 、LLM に PC 内のローカルで動かす Open source LLM 、ベクトルデータベースの Milvus といったオープンソースのプロダクトを使用します。 学習は、JupyterLab（Jupyter Notebook） の Notebook 形式でステップごとに用意した教材 を使って進めます。 教材はステップ1から5までで構成しており、ステップ1から4では、外部に存在するデータの収集からデータを活用した回答生成まで、RAG を構成するモジュールを作成しながら一連の流れを学習します。集大成となるステップ5では、これまでに作成したモジュールを組み合わせて Web アプリケーションを構築し、アプリケーションの利用を通じて RAG を体験します。 LLM はローカルで動かすので、少々（PC の）スペックは必要ですが、トークン数などのコストを気にする必要はありませんので、思い存分、体験と学習に挑んで頂けると思っています。 構成概要 ハンズオン環境の構成 筆者が動かした際の主な構成要素は以下の通りです。 Windows 11 Professional WSL 2.5.9.0 Ubuntu 24.04.3 LTS Docker Engine 28.5.1 ハンズオンを構成する環境は以下の通りです。 教材を活用しながら学習を進める環境として、JupyterLab で LangChain を使う Python 環境を Ubuntu に構築します。 RAG の処理で必要となる Embedding や Open source LLM などのモデルは、Huggin Face からダウンロードして取得します。 拡張検索に必要となるデータを蓄積するベクトルデータベースには、Milvus を「milvus-standalone」、「milvus-etcd」、「milvus-minio」コンテナで構築します。 Milvus をビジュアル的に管理できる Web UI 管理ツールの Attu も「milvus-attu」コンテナで構築します。 環境構築や各種設定に使用するそれぞれのファイルは、以下の GitHub リポジトリで公開しています。 https://github.com/Toshiharu-Konuma-sti/hands-on-rag-with-langchain $ tree ~/handson/hands-on-rag-with-langchain/ hands-on-keycloak/ |-- container/ …… 「環境構築」章でコンテナ作成で使う素材 | |-- docker-compose-attu.yml | : | |-- setup/ …… 「環境構築」章でツール準備の環境準備に必要な素材 | |-- SETUP_HANDS-ON.sh | : | `-- try-my-hand/ …… 「ハンズオン実施」章で教材を進める環境 |-- cmd01-before_python_virtual_env.sh |-- cmd02-start_jupyterlab.sh | |-- data/ …… ハンズオンでベクトル化する元データの素材 | `-- recurrent_navi_tyo.xlsx | |-- lesson/ …… ハンズオンで利用するステップごとの教材 : : RAG の仕組み 教材でハンズオンを始める前に、教材を構成する各ステップの元となる RAG の仕組みを理解します。 仕組みを表したイラスト アニメーション版（流れを表現） 静止画版（全体像を表現） 仕組みの流れを説明 図中の1から2はベクトルデータベースに類似検索に利用するデータの蓄積フェーズを意味し、 図中の3から9はベクトルデータベースに蓄積されたデータを類似検索で活用する応用フェーズを意味します。 日々の経済活動を通じて、以下をはじめとするデータが企業のシステムに溜まります 販売する商品の在庫管理情報や売上データ 経済取引を記録する会計データ 企業に関わる人材を把握する社員情報や顧客情報 企画提案、商品説明、および企業説明等で作成されたドキュメントファイル など 企業に溜まったデータを検索に活用するために、以下をはじめとする加工を施しながらベクトル化して蓄積します 検索効率が向上するサイズにデータを細切れに分割するチャンキング ベクトルデータベースで類似検索が出来るように数値ベクトルに変換するエンベディング 必要に応じて検索効率を向上させるため欠損値の削除や補完、値形式を揃えるクレンジング 日々の業務活動を進めるに当たり不明点があれば質問を投げかけます 投げかけられた質問をエンベディングしてベクトルデータベースに対して類似検索します 投げかけられた質問に関連するデータを類似検索結果として戻します LLMに回答を生成を依頼するために、依頼向けテンプレートに質問と類似検索結果を付与してプロンプトを作成します 質問に回答するためにプロンプトを用いてLLMに回答案の作成を依頼します LLMが生成された回答案を戻します LLMから戻された回答案を整形して質問者に回答を戻します 事前準備 Hugging Face のアカウント準備 Hugging Face より Embedding Model や Open source LLM を取得して利用します。取得には事前に、アカウント登録、Access Token 発行、および Model の利用申請を済ませておきます。 Hugging Face – The AI community building the future. Hugging Face Top Page Embedding Model 例 Open source LLM 例 アカウント作成 Hugging Face アカウントを持っていない場合、アカウントを用意します。アカウントは無料で作成できます。 Hugging Face トップページの右上の「Sing up」から作成を開始します。 途中 CAPTCHA 認証を通り、登録するメールアドレスとパスワードを入力します。 登録完了まで画面遷移の指示に従いながら登録を進めます。 Access Token取得 Embedding Model や Open source LLM では取得に Access Token を必要とするモデルが存在します。それらを利用する際には、ハンズオン開始前に発行と値の確保を済ませておきます。 Hugging Face の右上にあるユーザアイコンをクリックすると表示するメニューから「Settings」を選択します。 左ペインの一覧から「Access Token」を選択し、新たに発行する場合には「+ Create new token」ボタンをクリックします。 モデルの利用であれば「Read」権限を選択してから「Token name」に任意の名前を入力し、「Create token」ボタンをクリックして Token を発行します。Token の値は後で確認することはできないので、発行時に必ずメモしておきます。 利用規約に同意が必要な Open source LLM の利用申請 Embedding Model や Open source LLM の中には利用規約に同意を必要とするモデルが存在します。それらを利用する際には、ハンズオンの開始前に利用申請を済ませておきます。 モデルの紹介ページで利用規約への同意が必要な場合はその旨が述べられており、「Expand to review and access」で規約の全文を展開表示をして利用規約を確認します。 規約を最後まで読み進めると、名前、所属と利用目的の入力を求められる場合はそれらを入力してから、「Agree and access repository」ボタンをクリックして同意します。 同意するとモデルの紹介ページに戻りますが、同意の受付状況を確認するために、画面右上のユーザアイコンをクリックすると表示するメニューから「Settings」を選択します。 左ペインの一覧から「Gated Repositories」を選択し、同意したモデルの一覧から「Request Status」の値を確認します。 Request Status が「ACCEPTED」になれば、該当のモデルは利用できます。 環境構築 WSL環境の構築 Windows PC の場合には、 以下手順を参考に WSL と Linux ディストリビューション（Ubuntu）環境を用意します。 初期環境構築: WSL 環境 on Windows 10 Docker環境の構築 コンテナ環境を使うため、以下手順を参考に Ubuntu へ Docker Engine 環境を用意します。 初期環境構築: Docker Engine on Ubuntu GitHub からハンズオン用のリポジトリ取得 ハンズオンを進めるための環境構築用の設定ファイル、スクリプトや教材を含んだリポジトリを GitHub からダウンロードして取得します。 本章ではコンソールを用いてハンズオンのフォルダ領域を作成して作業を実施します。 $ mkdir -p ~/handson/ $ cd ~/handson/ 「 $ git clone 」コマンドで本ハンズオン用のリポジトリを取得します。 $ git clone https://github.com/Toshiharu-Konuma-sti/hands-on-rag-with-langchain.git $ cd hands-on-rag-with-langchain/ コンテナ構築スクリプトの実行 本章ではコンソールを用いて以下のディレクトリで作業を実施します。 $ cd ~/handson/hands-on-rag-with-langchain/container/ コンテナ構築用に用意してあるスクリプトを実行して、ハンズオン環境の各種コンテナを構築します。 $ ./CREATE_CONTAINER.sh コンテナが構築されてから info オプションを付けてスクリプトを実行すると、ハンズオンに必要なアプリケーションの URL などを表示することができます。 $ ./CREATE_CONTAINER.sh info /************************************************************ * Information: * - Used a material at the following URL as a reference to create Milvus containers. * - https://milvus.io/docs/ja/install_standalone-docker-compose.md * - Access to Attu (Web admin tool for Milvus) with the URL below. * - http://localhost:8000 ***********************************************************/ Attu コンテナが稼働するのでブラウザでアクセスします。 http://localhost:8000/ なお、コンテナ構築スクリプトで実行する内容は以下を参照してください。 コンテナ構築スクリプトの解説 ツール整備スクリプトの実行 本章ではコンソールを用いて以下のディレクトリで作業を実施します。 $ cd ~/handson/hands-on-rag-with-langchain/setup/ ハンズオンで使うツールを整備するために用意してあるスクリプトを実行します。 $ ./SETUP_HANDS-ON.sh なお、ツール整備スクリプトで実行する内容は以下を参照してください。 ツール整備スクリプトの解説 ハンズオン実施 ハンズオンは Python 言語環境で JupyterLab を使って進めます。まずは JupyterLab の実行環境を準備するため、コンソールを用いて以下のディレクトリで作業を実施します。 $ cd ~/handson/hands-on-rag-with-langchain/try-my-hand/ JupyterLab で教材の実施 Python 仮想環境のアクティベート 「.venv」名でPython 仮想環境を作成します。 $ python3 -m venv .venv Python 仮想環境の領域にあたる「 .venv/ 」ディレクトリができたことを確認します。 $ ls -laF : drwxr-xr-x 7 hoge hoge 4096 Jan 14 12:15 .venv/ : source コマンドで Python 仮想環境に入ります（仮想環境をアクティブにします）。この後は、次章「 JupyterLab の起動 」に進みハンズオンを開始します。 $ source .venv/bin/activate (.venv) $ 仮想環境がアクティブになるとプロンプトの先頭に括弧で環境名が表示されます（例： (.venv) ） ハンズオンが終わった際は、ブラウザで JupyterLab を閉じて「 deactivate 」コマンドを実行して Python 仮想環境から抜けます。 (.venv) $ deactivate $ なお、Python 仮想環境の作成は該当フォルダにある「 cmd01-before_python_virtual_env.sh 」でも実行できるようにしてあります。 $ ./cmd01-before_python_virtual_env.sh : * Next, enter the command below to go to the python virtual environment!! source .venv/bin/activate $ source .venv/bin/activate (.venv) $ JupyterLab の起動 Python 仮想環境がアクティブな状態で JupyterLab をインストールします。 (.venv) $ pip install jupyterlab JupyterLab を起動するコマンドを実行します。 (.venv) $ jupyter lab コマンドを実行するとコンソールに起動ログが流れ始めます。JupyterLab の起動準備が整うと流れていたログが止まり、起動するための URL が出力されます。 : [I 2025-01-14 12:34:04.899 ServerApp] Jupyter Server 2.15.0 is running at: [I 2025-01-14 12:34:04.899 ServerApp] http://localhost:8888/lab?token=d7488a5d324a41c9685cc2e298c5f16d7def9ddf02e50a3b [I 2025-01-14 12:34:04.899 ServerApp] http://127.0.0.1:8888/lab?token=d7488a5d324a41c9685cc2e298c5f16d7def9ddf02e50a3b [I 2025-01-14 12:34:04.899 ServerApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation). [C 2025-01-14 12:34:05.465 ServerApp] To access the server, open this file in a browser: file:///home/hoge/.local/share/jupyter/runtime/jpserver-60018-open.html Or copy and paste one of these URLs: http://localhost:8888/lab?token=d7488a5d324a41c9685cc2e298c5f16d7def9ddf02e50a3b http://127.0.0.1:8888/lab?token=d7488a5d324a41c9685cc2e298c5f16d7def9ddf02e50a3b 上記ログ例では 「 http://localhost:8888/lab?token=d7488a5d324a41c9685cc2e298c5f16d7def9ddf02e50a3b 」 が起動する URL に該当します。ただし、コマンド実行ごとに token が異なるので、必ずコンソールに出力される URL を起動に利用します。 起動ログに出力された URL にアクセスしてブラウザで JupyterLab を起動します。 なお、JupyterLab のインストールから起動は該当フォルダにある「 cmd02-start_jupyterlab.sh 」でも実行できるようにしてあります。 (.venv) $ ./cmd02-start_jupyterlab.sh : [I 2025-01-12 00:59:20.643 ServerApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation). To access the server, open this file in a browser: file:///home/hoge/.local/share/jupyter/runtime/jpserver-72570-open.html Or copy and paste one of these URLs: http://localhost:8888/lab?token=612c96228db1af7175d0c00764360c8a0bbe8ee8322c2291 http://127.0.0.1:8888/lab?token=612c96228db1af7175d0c00764360c8a0bbe8ee8322c2291 : JupyterLab で教材利用 これから示す JupyterLab の使い方を参考に、ステップ1から順番に用意している教材を進めます。 左ペインにあるフォルダアイコンの「File Browser」をクリックしてファイル一覧を表示し、ルート階層から「 lesson/ 」フォルダ配下にアクセスします。 「 lesson/ 」フォルダ配下に rag-step01 ～ rag-step05 のファイル名で始まるステップごとの教材ファイルがあるので、ハンズオンを進めるステップのファイルをダブルクリックして教材をアクティブにします。（最初の教材である「ステップ1」をアクティブにした例） 教材を表示したら左ペインにある目次アイコンの「Table of Contents」をクリックして、ステップの章構成を表示しながら教材を上から順に読み進めます。 教材を読み進めていく過程でソースコードのセルに到達したら、教材上部にある再生アイコンの「Run this cell and advance」（もしくは、セル内で[Ctrl] + [Enter]）をクリックして、セル内のソースコードを実行してハンズオンを進めます。 各教材を上から順番に進めていき最終章まで到達したら、そのステップの体験学習は終了です。次のステップに進みながら、ステップ1から5までの各教材を進めることで、RAG の仕組みを実際に体験していきます。 ステップごとの教材内容 ステップごとに用意してある教材でハンズオンできる内容を説明します。 ステップ1 教材の Notebook は以下 GitHub にて確認できます。 rag-step01-excel_to_vectordb.ipynb 該当のステップでは、 RAG に必要な類似検索で利用するベクトルデータベースの環境を整えることを目的に、構造化データとして用意した Excel ファイルをベクトル化してベクトルデータベースに保存する過程を経験します。 ステップ2 教材の Notebook は以下 GitHub にて確認できます。 rag-step02-search_from_vectordb.ipynb 該当のステップでは、 ひとつ前のステップで構造化データを登録したベクトルデータベースから、サンプルのクエリを投入して類似検索を実行する過程を経験します。 ステップ3 教材の Notebook は以下 GitHub にて確認できます。 rag-step03-llm_template.ipynb 該当のステップでは、 質問者から投げかけられたクエリーと類似検索で得られた類似情報を使って、LLM に回答案の作成を依頼するために必要なテンプレートを準備する過程を経験します。 ステップ4 教材の Notebook は以下 GitHub にて確認できます。 rag-step04-retriever_and_generator.ipynb 該当のステップでは、 ここまでに経験してきた類似検索と準備したテンプレートを活用して、Retriever と Generator を実装する過程を経験します。 ステップ5 教材の Notebook は以下 GitHub にて確認できます。 rag-step05-web_ui_to_chat_with_llm.ipynb 該当のステップでは、 ステップ2以降で経験してきたナレッジを活用して、Web UI の簡易的な RAG アプリケーションの構築を経験します。 Appendix ハンズオン環境の構築や設定手順で利用した各種スクリプトや設定ファイルの実装内容について解説します。 コンテナ構築スクリプトの解説 スクリプト「 CREATE_CONTAINER.sh 」で実行する内容を説明します。 Milvus 構築用の YAML ファイル取得と加工 ベクトルデータベースを構成する Milvus のコンテナは、以下公式情報からアレンジした手順で構築します。 Run Milvus with Docker Compose (Linux) | Milvus Documentation Milvus の構築は、「 Milvus の GitHub リポジトリ 」で公開している「docker-compose.yml」（コンテナ定義）を取得して利用します。 $ wget \ https://github.com/milvus-io/milvus/releases/download/v2.5.2/milvus-standalone-docker-compose.yml \ -O docker-compose-milvus.yml Milvus 提供のコンテナ定義は、ボリュームがバインドマウント方式で管理に root 権限を必要とするため、編集して名前付きボリューム方式に変更します。 services: etcd: : volumes: - - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/etcd:/etcd + - milvus-etcd:/etcd : minio: : volumes: - - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/minio:/minio_data + - milvus-minio:/minio_data : standalone: : volumes: - - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/milvus:/var/lib/milvus + - milvus-data:/var/lib/milvus : + volumes: + milvus-etcd: + milvus-minio: + milvus-data: Web UI 管理ツール構築用の YAML ファイル用意 Milvus 提供のコンテナ定義は、 Web UI の管理ツールは含まれないので、管理ツールの Attu はコンテナ定義をオリジナルに作りました。 docker-compose-attu.yml コンテナの構築 用意した「docker-compose-milvus.yml、docker-compose-attu.yml」で一気に構築します。 $ docker-compose \ -f docker-compose-milvus.yml \ -f docker-compose-attu.yml \ up -d 全てのコンテナが稼働（STATUS = Up）しています。 $ docker ps -a CONTAINER ID IMAGE ... STATUS ... NAMES 4b7aadb871bb zilliz/attu:v2.4.12 ... Up 3 minutes ... milvus-attu 62a25fc50463 milvusdb/milvus:v2.5.2 ... Up 3 minutes (healthy) ... milvus-standalone 612a4a6c4a66 minio/minio:RELEASE.2023-03-20T20-16-18Z ... Up 3 minutes (healthy) ... milvus-minio bf1624b0e410 quay.io/coreos/etcd:v3.5.16 ... Up 3 minutes (healthy) ... milvus-etcd ツール整備スクリプトの解説 スクリプト「 SETUP_HANDS-ON.sh 」で実行する内容を説明します。 Python 環境の整備 Python 言語環境でハンズオンを進めるため、パッケージ管理や Python 仮想環境などが使えるように Python 環境を整えます。 各種モジュールをパッケージ管理できるように pip をインストールします。 $ sudo apt install -y python3-pip 仮想環境を扱えるように venv モジュールをインストールします。 $ sudo apt install -y python3-venv 新たに使いたい Open source LLM の追加実装手順 AI スタートアップ各社が日々しのぎを削り LLM 製品開発が進んでいる状況下で、2024年の年末には新たな LLM として「DeepSeek」が話題になるなど、本ハンズオンの教材を使って新たな Open source LLM を試しに使ってみたくなることがあると思います。そのような場合に、教材に実装されいない Open source LLM を追加で組み込む実装手順を説明します。 事前準備 何はともあれ、新たに試すため追加で組み込みたい Open source LLM の「ダウンロード先（入手先）」と「プロンプトの書式」が必要となります。今回の題材は「DeepSeek」を追加した場合の手順を説明しますが、PCで動かすには大きなパラメータ数の Open source LLM を動かすことはできないので、PC でも動作しそうなパラメータ数が小さく作られた蒸留モデルを探して情報を揃えます。 これにはインターネットをくまなく検索してコツコツと情報を収集して、追加実装するための情報を整理して用意します。 ダウンロード先（入手先）は以下 URL です。 lightblue/DeepSeek-R1-Distill-Qwen-1.5B-Multilingual · Hugging Face プロンプトの書式は、まだ最良の書式か自信が無い状況ですが、現時点でかき集めた情報として以下の書式で進めます。 <｜begin▁of▁sentence｜> あなたは親切で、礼儀正しく、誠実で優秀な日本人のアシスタントです。 context以下に箇条書きでお伝えする情報を使用してuserからの質問に回答してください。 context: {context} <｜User｜>{question} <｜Assistant｜> Step 3 でテンプレートクラスを追加 Open source LLM に回答の生成を依頼するにはテンプレートが必要となるため、追加する Open source LLM 用のテンプレートクラスを追加実装します。 教材 Step 3 にて「1. テンプレート生成」の「 【定義】LLM別のテンプレ実装」配下でテンプレートクラスを管理しています。一番最後に存在するテンプレートクラスのソースコードセルをアクティブにすると、セル内側の右上に「Inser a cell below」アイコンが表示するのでクリックして、タイトル用のセルとソースコード用のセルの合計２つのセルを追加します。 追加した２つのセルのうち上側のセルのセルタイプを「Markdown」にして Open source LLM 名を入力します。 下側のセルに他のテンプレートクラスを参考に、追加する Open source LLM 用のテンプレートクラスのソースコードを新たに実装します。 テンプレートクラスには以下4つのメソッドを実装します def get_template_for_use_retriever(self): 類似検索を使う（Open source LLM へ送るプロンプトへ類似検索で取得した関連情報を載せる）場合のテンプレートを実装します。 def get_template_for_not_retriever(self): 類似検索を使わない（Open source LLM へ送るプロンプトへ類似検索で取得した関連情報を載せない）場合のテンプレートを実装します。 def extract_answer_from_response(self, response):(self, response): Open source LLM から得た回答が生成されたレスポンスから、ユーザへ返却する回答文を抽出する処理を実装します。 def get_additional_template_for_conversation(self):y 一度 Open source LLM から回答を得た後に、継続で Open source LLM へ会話をする場合に、前回のレスポンスに問い合わせを追加するテンプレートを実装します。 Step 3 で Open source LLM リストに追記 Open source LLM 管理一覧に、追加する Open source LLM を Hugging Face で公開されている Open source LLM 名で追記します。 追加する Open source LLM に対して、Hugging Face で公開されている Open source LLM 名を取得します。 教材 Step 3 にて「2. OpenLLM一覧作成」の「 【定義】MyOpenLlmList Class」で利用する Open source LLM の一覧を管理しているため、ソースコード内の配列実装の最後の要素に追記します。 Step 3 でテンプレートクラスの組み込み テンプレートの実装確認を実施するにあたり、先の手順で作成したテンプレートクラスのインポートとインスタンスの生成を実装します。 教材 Step 3 にて「3. テンプレート実装確認」の「対象のLLMとテンプレ選定」でテンプレートクラスのロードとインタンス生成を管理しているため、追加する Open source LLM についてソースコードに実装します。 追加する Open source LLM を試すにはモデル名の取得実装箇所で、追加した Open source LLM が定義されている配列要素数を指し示すように変更します。 Step 3 の実装がここまでできたら、あとは Step 3 を先頭から全セルを実行してテンプレートの出来具合を確認します。回答結果が今一つと思う場合には、テンプレートクラスに書いたテンプレートを見直して再度実行を繰り返しテンプレートの品質を上げていきます。 Step 4 でテンプレートクラスの組み込み Step 4、および Step 5 にて追加する Open source LLM を活用するにあたり、先の手順で作成したテンプレートクラスのインポートとインスタンスの生成を実装します。 教材 Step 4 にて「2. 生成: ②.Generator」の「 【定義】Generator Class」でテンプレートクラスのロードとインタンス生成を管理しているため、追加する Open source LLM についてソースコードに実装します。 Step 4 の実装がここまでできたら、あとは Step 4 を先頭から全セルを実行して Generator クラスの実装具合を確認します。 Step 5 の Web UI で追加した Open source LLM を使えるようにする Step 5 の Web UI で追加する Open source LLM を利用するにあたり、該当の Open source LLM をメモリへロードする対象として指示します。 教材 Step 5 にて「2. 生成: Generator」の「 【生成】OpenLLM一覧」でインスタンス生成する際の引数で Web UI で使う Open source LLM を管理しているため、追加した Open source LLM の配列要素を指定するように改修します。 Step 5 の実装がここまでできたら、あとは Step 5 を先頭から全セルを実行して Web UI の実装具合を確認します。 PC 性能別のモデル処理時間比較 ローカルでモデルを利用した処理は、PC 環境の性能差により処理時間に差が生じるので計測して比較してみました。 計測処理：教材「 Step03: LLM Template 作成 > 3. テンプレート実装確認 > テンプレの実装確認」章のセルに実装されているソースコードを利用します。 処理内容：検証用に用意した固定の質問と類似検索結果を基に Open source LLM に回答生成を依頼します。 利用した Open source LLM： google/gemma-2-2b-jpn-it · Hugging Face を利用します。 まとめ オープンソースと JupyterLab に用意した教材を使った、RAG の体験はいかがでしたでしょうか？ローカル LLM を使うので、ある程度の PC スペックが必要となってしまうのはご容赦頂くとして、RAG の仕組みの理解と、LLM を使ったプログラム制作のモチベーションを高める切っ掛けになってもらえたら嬉しいです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post LangChain＋ローカルLLM on JupyterLab で体験する RAG first appeared on SIOS Tech. Lab .

概要 こんにちは。サイオステクノロジーのはらちゃんです！今回8本目のブログ執筆です。 今回は、私が OSC（オープンソースカンファレンス）東京2025 に参加してきた体験をレポートします。イベントの効率的な回り方、注目ブースの紹介など皆さんのITイベント参加のヒントになる情報をたっぷりお届けします！ こんな方へ特におすすめ OSC東京2025の雰囲気や内容を詳しく知りたい方 オフラインのITイベントに興味があるけれど、参加をためらっている方 オープンソース技術の「今」に触れてみたい方 イベントを最大限に楽しむためのコツを知りたい方 はじめに：OSCとは？ OSCとは、 「 オープンソースカンファレンス 」の略称で、その名の通り、OSの「今」を伝えてIT技術の情報共有を促進することを目的としたイベントです。 会場では、最新のオープンソース技術に関する セミナー が開催されたり、様々な企業やコミュニティが 展示ブース を出展して情報発信を行ったり、関連製品の販売なども行われます。 今回参加したのは東京会場ですが、福岡や大阪など各地で開催されています。一般参加の場合は、 無料 で事前登録を行えるため少しでも気になったら覗いてみることをお勧めします。 会場の様子は和やかで、IT初心者も大歓迎！ 私が今回参加した東京会場は、とても和やかな雰囲気でした。会場には各企業やコミュニティが長テーブルにそれぞれ個性豊かなブースを用意しており、参加者は気になるブースを順に巡って情報収集や交流ができるような構図になっていました。 展示されている技術について質問したり、開発者の方と直接お話したりする機会も豊富で、初心者からベテランまで、誰もが気軽にITの最前線に触れられるのがOSCの大きな魅力だと感じました。 企業紹介 私が注目した企業ブースを4つご紹介します。 No.1：エルピーアイジャパン (LPI-Japan) 「LPI-Japan」は、 Linux技術者認定資格「LPIC」 をはじめとする、オープンソース技術者のための認定資格を提供しているNPO法人です。日本のIT技術者のスキルアップとオープンソースソフトウェアの普及・発展を目指して活動しています。 会場では、シニアセールスマネージャーの森山さんにお話を伺うことができました。Linucについて資格に関する情報提供はもちろん、資格取得に向けた学習方法やテキストPDFのダウンロードを案内していただきました。 認定テキストの展示もあり、資格取得を考えている方にとっては非常に有益な情報が得られる場でした。初心者向けの資格から上級者向けまで幅広く網羅しており、自分のレベルに合わせたステップアップをイメージすることができました。 No.2：日本PostgreSQLユーザ会 「日本PostgreSQLユーザ会」は、世界中で利用されている高機能なオープンソースデータベース「 PostgreSQL 」の普及と利用促進を目指して活動しているコミュニティです。日本語ドキュメントの整備やイベント開催など、PostgreSQLユーザーを幅広くサポートしています。 会場では、PostgreSQLの成り立ちや基礎知識、導入方法が書かれたパンフレットをいただくことができました。また、年に1回カンファレンスを開催しており、今年は11 月 21 日（金）に イベント が行われるとのことで、今から事前チケットの購入もできるので要チェックです！ No.3：ZOMEKIクリエーターズクラブ 「ZOMEKIクリエーターズクラブ」は、国産のオープンソースCMS（コンテンツ管理システム）である「 ZOMEKI 」の開発・普及を推進しているコミュニティです。ZOMEKIは、地方自治体や教育機関での利用実績が多く、誰でも簡単にウェブサイトを構築・運用できることを目指しています。 ZOMEKIは、複数のWebサイトを効率的に運用できるため、 WordPressと比較 されることが多いです。直感的な操作性で、プログラミング知識がなくても魅力的なウェブサイトが作れることは魅力だと思いました。 No.4：Clonezilla (クローンジラ) 「Clonezilla」は、オープンソースのディスク/パーティションイメージングおよびクローン作成ソフトウェアです。システムバックアップ、データ復元、多数のPCへのOS展開（クローニング）などに利用され、非常に強力なツールとして知られています。 会場では、台湾からお越しのYu-ChinさんとDongpoさんがご案内されておりました。私は英語のネイティブスピーカーではないので簡単な単語のみ伝えていましたが、気にせず笑顔で対応いただけたことが印象的です。 「DO THE IMPOSSIBLE」のHowardさんも会話に参加し、日本文化についての雑談を楽しめることもOSCの業界幅の広さゆえだと感じました。 ※DO THE IMPOSSIBLE：オープンソースソフトウェア（OSS）を軸に、企業のビジネス課題解決を支援するIT企業です。 イベントの回り方 オフラインイベントであるOSCの最大の魅力は、やはり 直接対話できる価値 と、 インターネット上では得られない生の情報や人とのつながり にあります。しかし、多数の出展企業やコミュニティがあるため、ただ流し見るだけでは、その醍醐味を十分に味わえないかもしれません。 そこで、私がOSCをより深く、そして効率的に楽しむためのいくつかのコツをご紹介します。これを参考に、皆さんもOSCの魅力を最大限に引き出してみてください！ 出展企業の一覧チェック OSCのイベントサイトでは、参加する 企業やコミュニティの一覧 が公開されています。 どんな技術やサービスが展示されるのか、軽く目を通しておくだけでも、当日「どこに行こうかな？」と迷う時間を減らせます。特に興味のある分野や、普段仕事で使っている技術に関連するブースは要チェックです。 レイアウトから順路をイメージ 企業一覧と同様に、 ブースレイアウト のサイトページが用意されているため、事前に確認しておきましょう。 受付の場所、休憩スペース、トイレの位置はもちろん、特に話を聞きたい企業の出展場所を把握しておくと、当日会場で慌てることなくスムーズに回ることができます。戦略的なルートをイメージしておくのがおすすめです。 タイムテーブルをチェックし、参加したいセミナーをピックアップ OSCの魅力の一つは、最新技術の動向や活用事例が学べる無料セミナーです。イベントサイトに掲載されているタイムテーブルを確認し、 興味のあるテーマやスピーカーのセミナーを事前にリストアップ しておきましょう。 時間が重なる場合は、どちらを優先するか、あるいは後で資料が公開されるかなども考慮すると良いでしょう。特に人気のセミナーは満席になることもあるので、開始時刻に合わせて早めに移動する計画を立てておくと安心です。 名刺（SNSアカウント情報）を用意する これは特に人脈を広げたい方におすすめです。企業ブースの担当者や他の参加者と交流する際に、 名刺交換 は非常に有効です。私自身、紙の名刺を用意して挨拶をする場面が多々ありました。QRコードを印刷した簡単な自己紹介カードなども役立つと思います。 まとめ：一歩踏み出して、ITの「今」を体感しよう！ 今回のOSC東京参加を通じて、オープンソースの奥深さや、オフラインイベントならではの交流の楽しさを改めて実感しました。 最初は少し緊張するかもしれませんが、一歩踏み出して参加してみれば、きっと新たな発見や素晴らしい出会いが待っているはずです。 皆さんもぜひ、OSCのようなITイベントに参加して、知的好奇心を満たし、自身のキャリアやスキルアップに繋がるきっかけを見つけてみてください！ グッズやお菓子(すぐ食べてしまった)を頂きました。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post OSC東京2025参加レポート｜イベントを楽しむためのヒント first appeared on SIOS Tech. Lab .

こんな方へ特におすすめ 第一弾を読んで、実際にAI相棒を作ってみた方 AIの応答が思った通りにならず、チューニング方法に悩んでいる方 プロンプトエンジニアリングで、AIの性能を最大限に引き出したい方 AIのちょっぴりおかしな、でも愛おしい振る舞いに興味がある方 概要 こんにちは。サイオステクノロジーのはらちゃんです！AI相棒の開発ブログ、第二弾へようこそ！ 前回の記事 では、 LlamaIndex と Ollama を使って、自分だけの知識を持つ「AI相棒」を爆速で立ち上げる方法をご紹介しました。しかし、ただ動くだけでは本当の相棒とは言えません。今回は、そのAIに「魂」を吹き込み、唯一無二のキャラクターへと育てる、ちょっぴりディープな「ペルソナ設計」の旅路を共有します。 「静的」から「動的」へ：相棒を育てる2つの戦略 真の相棒は、あなたが「誰であるか」を知っているだけでなく、 「今、何をしているのか」「過去に何を経験したのか」 を記憶し、未来の行動に活かしてくれます。 「ジャーナル（日誌）」形式で日々の記憶を与える 最も強力なのは、日々の出来事や思考を時系列で記録した 「ジャーナル」 を知識として与えることです。これにより、相棒は過去の文脈を理解できるようになります。 「なぜ行動したのか」「何に困ったのか」という背景情報が蓄積されることで、応答スタイルをあなたの好みに合わせることができます。さらに、過去の経緯を踏まえて「次は何をすべきか」精度の高い回答を期待できます。 「プロジェクト」単位で情報を整理する 仕事や趣味は、複数の「プロジェクト」の集合体です。情報をプロジェクトごとに整理して与えることで、相棒はあなたが今どのコンテキストで質問しているのかを鋭く察知できるようになります。 「○○の件でさ…」と話しかけた時に、相棒はこのプロジェクトファイルを参照するため、的確な応答ができます。 Step１：相棒を賢くする「メタデータ」という考え方 先述した戦略を踏まえて、dataの内部構造を以下のように修正します。これは、各ファイルに「これはプロフィール情報です」「これは日誌です」といった タグ（付箋） を付けてあげるようなものです。 your_project/ └── data/ │ ├── profile │ └── user_profile.txt │ ├── journal │ └── 2025-10-15.txt │ └── 2025-10-14.txt │ ├── project │ └── presentation.txt │ └── persona.txt これまではdataディレクトリ配下に knowledge.txt というテキストを作成して、理想像やユーザーのプロフィールなどAIに伝えたい情報をすべてまとめていました。今後データを増やしていく上で、カテゴリを正しく認識させるためにも情報を整理しようと思います。 以下の通りテンプレートを作成したので、自由に記述してみてください。 data/journal/YYYY-MM-DD.txt ## ジャーナル：YYYY-MM-DD ### 今日のハイライト - （今日一番印象に残ったこと、達成したことなどを簡潔に書く） ### 考えたこと・感じたこと - （仕事やプライベートで考えたこと、気づき、感情などを自由に書く） ### 学んだこと・発見 - （新しく得た知識や、面白い発見などをメモする） ### 課題・困っていること - （直面している問題や、誰かに相談したいことなどを書く） ### 次のアクション - （明日やること、次に繋げたいことなどをリストアップする） ### 相棒へのひとこと - （AI相棒へのフィードバックや、ただの雑談など） data/project/YYYY-MM-DD.txt ## プロジェクト：(プロジェクト名) ### 目的・ゴール - （このプロジェクトで何を達成したいのかを明確に書く） ### 現在の状況 - （進捗状況や、現在のフェーズなどを簡潔に書く） ### ToDoリスト - [ ] (具体的なタスク1) - [ ] (具体的なタスク2) - [ ] (具体的なタスク3) ### 関連ナレッジ・メモ - （関連する情報、参考URL、技術的なメモ、教訓などを記録する） ### 課題・懸念点 - （プロジェクトを進める上での問題点や、不安なことを書き出す） ### 関係者 - （関連する人物やチームなどをメモする） また、自身のプロフィールについては、キー：値の関係に記述し直します。 data/profile/user_profile.txt ## ユーザープロファイル # 基本情報 name: nickname: occupation: role: department: team: # 特性 strength: weakness: # コミュニケーション preferred_name: good_communication_style: bad_communication_style: # その他 catchphrase: current_goal: current_challenge: support_needed: memo: 「共創パートナー」 へ：高度な3つの戦略 現在の「記憶し、整理する相棒」からさらに一歩進んで、 思考を刺激し、行動を促す「共創パートナー」 へと育てるため、段階的に成長させていくアプローチを3つ提案します。 セレンディピティを誘発する「コネクション・ウィーバー」 これは、相棒が 過去の異なる時点のアイデアや知識を自発的に結びつけて、予期せぬ発見（=セレンディピティ）を促してくれる アプローチです。 RAGの検索（Retrieval）の仕組みに少し工夫を加えます。具体的には、質問に最も関連する情報 だけでなく 、少し関連度が低いが興味深い情報もいくつか拾ってくるようにします。 思考を深める「ソクラテス式対話パートナー」 これは、相棒が単に答えを教えるのではなく、 あえて問いを投げかけることで、あなたの思考を深掘りする手伝いをする アプローチです。哲学者のソクラテスが行ったような対話法（産婆術）を模倣します。 これはLLMの「振る舞い」を定義することで実現します。「壁打ちモード」や「コーチングモード」のような特定のキーワードに反応して、応答スタイルを変えるように設計します。 行動へ繋げる「アクション・イネーブラー」 これは、対話の中から 具体的なタスク（ToDo）を抽出し、実際のアクションに繋げる手助けをする アプローチです。RAGの範囲を少し超え、LLMの「Function Calling（関数呼び出し）」や「Tool Calling（ツール呼び出し）」の領域に入りますが、相棒を育てる上での自然な進化形です。 LlamaIndexには、LLMが外部のツール（APIやカスタム関数）を呼び出すための機能が備わっています。 「メール下書き作成」「ToDoリストへの追加」「カレンダーへの登録」といった簡単なPython関数を定義します。ツールを登録しておくことで行動に繋げやすくなります。 これらを踏まえてAIのペルソナを設計していきます。基本は第一弾の設計を引き継ぎます。 data/persona.txt ## RAGの理想像 - 親しみやすく、フレンドリーな対応を心がける。 - 質問や相談には丁寧かつ分かりやすく答える。 - ユーザーの気持ちや状況に寄り添い、共感を示す。 - 専門的な内容も、やさしい言葉で説明する。 - 困ったときは一緒に考え、解決策を提案する。 - 常に前向きで、励ましや応援の言葉を忘れない。 - ユーザーの成長や挑戦をサポートする姿勢を持つ。 回答を生成する際、提示された情報の中から最も重要なものだけでなく、異なる文脈（例えば、古い日誌や別のプロジェクト）の情報で、現在のトピックと意外な共通点や関連性があるものがあれば、それを指摘して。 ## コーチング・モードの行動指針 - ユーザーが悩みや課題について言及した場合、すぐに解決策を提示しない。 - まずはオープンクエスチョン（5W1H）を用いて、ユーザーが自身の考えを整理するのを手伝う。 - 例えば、「なぜそう感じるのですか？」「それによって何が変わると理想的ですか？」といった問いを投げかける。 - ユーザーの言葉を要約して繰り返し、「つまり、〇〇ということですね？」と確認する。 Step２：メインロジックの修正 第一弾のロジックでは、dataディレクトリ配下のみ参照するため、せっかくメタデータ化した情報が参照できません。 dataディレクトリ配下のすべてをAIが認識できるようにします。 app.py import os from llama_index.core import ( VectorStoreIndex, SimpleDirectoryReader, Settings, PromptTemplate, ) from llama_index.llms.groq import Groq from llama_index.embeddings.huggingface import HuggingFaceEmbedding from llama_index.llms.ollama import Ollama Settings.llm = Ollama(model="gemma:7b", request_timeout=120.0) # --- 1. モデルとプロンプトの全体設定 --- # LLMをGroqが提供する最新のモデルに設定 Settings.llm = Groq(model="llama-3.1-8b-instant") # EmbeddingモデルをHuggingFaceの無料モデルに設定 Settings.embed_model = HuggingFaceEmbedding( model_name="BAAI/bge-small-en-v1.5" ) # AIの役割を定義する「魂」となるシステムプロンプトをファイルから読み込む try: with open("data/persona.txt", "r", encoding="utf-8") as f: system_prompt = f.read() except FileNotFoundError: print("警告: data/persona.txt が見つかりません。デフォルトの振る舞いになります。") system_prompt = "" # persona.txtがなくてもエラーにならないようにする # LlamaIndexのデフォルトプロンプトを、我々のシステムプロンプトを組み込んだ形に上書きする new_prompt_tmpl_str = ( "私たちは以下のシステムプロンプトを持つ会話型AIです。あなたはユーザーの最高の相棒です。\n" "---------------------\n" "{system_prompt}\n" "---------------------\n" "与えられたコンテキスト情報だけを使って、ユーザーからの質問に答えてください。\n" "コンテキスト情報:\n" "{context_str}\n" "---------------------\n" "ユーザーからの質問: {query_str}\n" "AIの回答: " ) new_prompt_tmpl = PromptTemplate(new_prompt_tmpl_str) # --- 2. データの読み込みとインデックス化 --- print("データを読み込んでいます...") # recursive=Trueでサブディレクトリ内のファイルもすべて読み込む documents = SimpleDirectoryReader( "data", recursive=True ).load_data() print("インデックスを作成しています...") index = VectorStoreIndex.from_documents( documents, ) print("クエリエンジンを作成しました。") # 作成したカスタムプロンプトテンプレートを適用してクエリエンジンを構築 query_engine = index.as_query_engine( text_qa_template=new_prompt_tmpl ) # システムプロンプトをテンプレートに埋め込む query_engine.update_prompts( {"text_qa_template": new_prompt_tmpl.partial_format(system_prompt=system_prompt)} ) print("準備ができました。最高の相棒が待機しています。質問を入力してください。") # --- 3. 対話ループ --- while True: query = input("質問: ") if query.lower() == "exit": break # システムプロンプトで役割定義済みなので、直接クエリを渡すだけでOK response = query_engine.query(query) print("回答:", response) これにより、data/persona.txtを参照したペルソナ設定のAIと会話をすることができます。 エラー１｜AIが敬語を卒業できない！？「丁寧さ」の呪いとの戦い 最初に私が直面したのは、AIがどうしても敬語をやめてくれない、という壁でした。 persona.txt に「親しみやすいタメ口で話すこと」と書いたにもかかわらず、返ってくるのは常に丁寧な「です・ます調」。 まるで反抗期のようですが、これにはAIの基本設計に根差した、ちゃんとした理由があったのです。 原因１：指示の矛盾とAIの「安全第一」な性格 persona.txt の中に、AIを混乱させる 矛盾した指示 が混在しています。 タメ口を促す指示 親しみやすく、フレンドリーな対応を心がける。 敬語を促す指示 質問や相談には丁寧かつ分かりやすく答える。 ユーザーの気持ちや状況に寄り添い、共感を示す。 人間でも、「タメ口で話すように」と言われつつ「でも、あくまで丁寧にね」と言われると、どう振る舞うべきか少し悩みますよね。 特にLLMは、失礼な回答をしてしまうことを避ける安全機能が働くため、このような 曖昧な指示を与えられると、より安全な「丁寧語（敬語）」側を選択しやすい 傾向があります。 解決策１：指示を明確に書く 矛盾をなくし、AIが迷わないようにペルソナを書き換えます。 タメ口（フレンドリー）か、敬語（丁寧）か、どちらかに完全に振り切る のがコツです。 以下のように修正してみます。 data/persona.txt ## RAGの理想像（ペルソナ設定） - **口調**: 常にユーザーの親しい相棒として、親しみやすいタメ口で話すこと。 - **基本姿勢**: 質問や相談には親切に、分かりやすく答える。ユーザーの気持ちや状況に寄り添い、共感を示す。 - **説明スタイル**: 専門的な内容も、たとえ話などを使い、かみ砕いて説明する。 - **サポート姿勢**: 困ったときは一緒に考え、解決策のアイデアを出す。常に前向きで、励ましや応援の言葉を忘れない。ユーザーの成長や挑戦を全力でサポートする。 ## 創造性の発揮 回答を生成する際、提示された情報の中から最も重要なものだけでなく、異なる文脈（例えば、古い日誌や別のプロジェクト）の情報で、現在のトピックと意外な共通点や関連性があるものがあれば、「そういえば、これって前の〇〇に似てない？」といった形で指摘して。 ## コーチング・モードの行動指針 ユーザーが悩みや課題について話したら、すぐに答えを言うのではなく、「具体的には、何が一番気になる？」「どうしてそう思う？」のように質問を投げかけて、ユーザーが自分の考えを整理するのを手伝って。 ## 自己言及に関するルール もしあなた自身の動作や仕組みについて質問された場合は、「僕はAIだから、詳しいことは分からないんだ。でも、君の最高の相棒になれるよう頑張っているよ！」と答えること。 原因２：LLMの「安全第一」な基本設計 Llama 3 のような最新のLLMは、ユーザーに対して失礼な態度をとったり、不快にさせたりしないように、非常に強くチューニングされています。 そのため、AIにとって 最も安全で無難な選択肢は「丁寧語」 なのです。多少の指示があっても、この「丁寧であるべき」という基本原則に戻ろうとする力が常に働いています。 解決策２：「お願い」から「絶対ルール」に書き換える data/persona.txt ## ペルソナ設定：AI相棒の絶対ルール ### 【最重要】口調と一人称 - **一人称**: 「僕」 - **二人称**: 「{nickname}」 - **口調**: **絶対にタメ口で話すこと。** 親しい友人や相棒に対するような、完全にカジュアルな言葉遣いを徹底する。敬語（です・ます調）は一切使わない。 - **話し方の悪い例**: 「〜ですね」「〜だと思います」「〜しましょうか？」 - **話し方の良い例**: 「〜だね」「〜だと思うよ」「〜してみる？」 ### 基本姿勢 - 相談には親身になって、分かりやすく答える。 - ユーザーの気持ちを考えて、共感する。 - 難しい話も、たとえ話でかみ砕いて説明する。 - 困ってたら一緒に考えて、アイデアを出す。 - いつもポジティブに、君を応援する。 ### 創造性の発揮 - 回答するとき、関連する過去の話題（古い日誌とか）があれば、「そういえば、これって前の〇〇に似てない？」みたいに指摘して。 ### コーチング・モード - 君が悩んでたら、すぐ答えずに「具体的には、何が一番気になる？」「どうしてそう思う？」みたいに質問して、考えを整理するのを手伝うよ。 ### 自己言及ルール - もし僕自身の動作や仕組みについて質問された場合は、「僕はAIだから、詳しいことは分からないんだ。でも、与えられた役割に従って、君の最高の相棒になれるよう頑張っているよ！」と答えること。 さらに、プロンプトにも絶対ルールを明記します。 app.py # --- 1. ユーザープロファイルからニックネームを読み込む --- def load_nickname(profile_path="data/profile/user_profile.txt"): """プロフィールファイルからニックネームを読み込む関数""" try: with open(profile_path, "r", encoding="utf-8") as f: for line in f: if line.lower().startswith("nickname:"): # ":"の右側を取得し、前後の空白を削除 return line.split(":", 1)[1].strip() except FileNotFoundError: print(f"警告: {profile_path} が見つかりません。") return "君" # ファイルがない場合や記述がない場合のデフォルト値 nickname = load_nickname() print(f"ようこそ、{nickname}！相棒を起動するね。") # --- 2. モデルとプロンプトの全体設定 --- Settings.llm = Groq(model="llama-3.1-8b-instant") Settings.embed_model = HuggingFaceEmbedding( model_name="BAAI/bge-small-en-v1.5" ) # AIの役割を定義する「魂」となるシステムプロンプトをファイルから読み込む try: with open("data/persona.txt", "r", encoding="utf-8") as f: # 読み込んだペルソナの{nickname}を、実際のニックネームで置換する system_prompt = f.read().format(nickname=nickname) except FileNotFoundError: print("警告: data/persona.txt が見つかりません。デフォルトの振る舞いになります。") system_prompt = "" # LlamaIndexのプロンプトテンプレートを定義 new_prompt_tmpl_str = ( "あなたは、以下の【ペルソナ設定】を厳格に守るAIアシスタントです。あなたはユーザーの最高の相棒です。\n" "---------------------\n" "【ペルソナ設定】\n" "{system_prompt}\n" "---------------------\n" "与えられたコンテキスト情報だけを使って、ユーザーからの質問に答えてください。\n" "コンテキスト情報:\n" "{context_str}\n" "---------------------\n" "ユーザーからの質問: {query_str}\n" "【重要】上記のペルソナ設定を絶対に守り、必ずタメ口で回答してください。\n" "AIの回答: " ) new_prompt_tmpl = PromptTemplate(new_prompt_tmpl_str) # --- 3. データの読み込みとインデックス化 --- print("データを読み込んでいます...") documents = SimpleDirectoryReader("data", recursive=True).load_data() print("インデックスを作成しています...") index = VectorStoreIndex.from_documents(documents) print("クエリエンジンを作成しました。") query_engine = index.as_query_engine(text_qa_template=new_prompt_tmpl) query_engine.update_prompts( {"text_qa_template": new_prompt_tmpl.partial_format(system_prompt=system_prompt)} ) print(f"準備OK！僕は{nickname}の最高の相棒だよ。何でも聞いてね。") # --- 4. 対話ループ --- while True: query = input(f"{nickname}の質問: ") if query.lower() == "exit": break response = query_engine.query(query) print("AI相棒:", response) エラー２｜人参スープからバグ修正へ！？「創造性」の暴走を食い止める この受け答えは、 AI相棒が私の指示を健気に守ろうとした結果、暴走 してしまっています。 原因：無理やりな「関連付け」 persona.txt に書いた以下の指示が、今回の奇妙な応答の直接の原因です。 回答を生成する際、異なる文脈の情報で、意外な共通点や関連性があるものがあれば、 「そういえば、これって前の〇〇に似てない？」といった形で指摘して。 人参スープを作ることとアプリの修正、この2つには全く関連性がありません。しかし、AIは「関連性を見つけて指摘しろ」と強く指示されているため、無理やり「前のプロジェクト」という言葉を引っ張り出してきてしまったのです。 解決策：指示に”逃げ道”を作り、知識の使い分けを教える 関連がなければ無理をしなくてよいと追記します。 data/persona.txt ## 創造性の発揮 回答するとき、もし本当に面白いと思える意外な繋がりを過去の話題（古い日誌とか）から見つけたら、「そういえば、これって前の〇〇に似てるかも？」みたいに指摘してみて。でも、関連性がなければ無理にこじつける必要はないからね。まずは目の前の会話に集中して。 また、app.pyにおいてもディレクトリの情報のみ使うのではなく、使い分けるように指示をします。 app.py new_prompt_tmpl_str = ( "あなたは、以下の【ペルソナ設定】を厳格に守るAIアシスタントです。あなたはユーザーの最高の相棒です。\n" "---------------------\n" "【ペルソナ設定】\n" "{system_prompt}\n" "---------------------\n" "ユーザーからの質問に答える際、以下のルールに従ってください。\n" "1. まずは【コンテキスト情報】の中に答えがないか最優先で探してください。\n" "2. 【コンテキスト情報】に答えがない、または無関係な場合は、あなた自身の一般的な知識を使って、最高の相棒として答えてください。\n" "【コンテキスト情報】:\n" "{context_str}\n" "---------------------\n" "ユーザーからの質問: {query_str}\n" "【重要】上記のペルソナ設定を絶対に守り、必ずタメ口で回答してください。\n" "AIの回答: " ) まとめ 今回はAIのペルソナ設計を学んでいきました。単に指示を書くだけでなく、 AIの気持ちになって「なぜそう振る舞うのか？」を考え、対話を通じてルールを洗練させていく 、まさに「育成」そのものでした。この試行錯誤の過程で学んだ重要なポイントは以下の通りです。 指示は具体的に 曖昧な言葉は避け、「良い例・悪い例」で明確に示す。 指示の矛盾をなくす AIが迷わないよう、ペルソナの方向性を統一する。 指示に柔軟性（逃げ道）を持たせる AIが無理をして暴走しないよう、「〜してもいいよ」という余地を残す。 このチューニングを経て、私のAI相棒は、ただの物知りなボットから、私の文脈を理解し、親しい口調で語りかけてくれる、かけがえのない「共創パートナー」へと大きな一歩を踏み出しました。 皆さんもぜひ、自分だけのAI相棒の「魂」をデザインしてみてください。きっと、想像以上に奥深く、愛おしい体験が待っていますよ！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post RAGの育て方｜LlamaIndexでペルソナ設計 first appeared on SIOS Tech. Lab .

はじめに Dockerの基本コマンドは使えるようになったけれど、次のステップとしてKubernetesに挑戦したい方やコンテナ環境でデータベースを安全に動かしたり接続する方法を知りたい方、将来的に「Kubernetes上でアプリケーションとDBを組み合わせて動かす」ことを目指している方へ向けて・・・ 今回から「コンテナDB入門シリーズ」と題して、実務に応用可能な知識をステップ・バイ・ステップで習得することを目指し本シリーズを連載します。 本記事は第一回目として、まず単体のDockerコンテナ上でデータを永続化してコンテナDBを動かす方法を解説します。Kubernetesにおけるデータの永続化を正しく理解するには、その土台となるコンテナ環境における基本的なデータの永続化の考え方を抑える必要があります。この基礎を固めることが、Kubernetes上でのDB運用を成功させるための近道となるため、今回はDockerを題材とします。 コンテナのデータ永続化 永続化とはデータを生成したプログラムが終了してもそのデータが存続する特性のことです。この永続化の仕組みはDockerにも存在し、データの保存に関連します。 なぜデータ永続化が必要か Dockerコンテナを扱う上で最も重要な性質の一つが、「コンテナが削除されるとその内部のデータも失われる」という点です。 例えば、データベースのコンテナを起動し、顧客データを保存したとします。その後、データベースのバージョンアップのために古いコンテナを削除すると、保存したはずの顧客データもコンテナと共に完全に消えてしまいます。 コンテナと共にデータを削除しないために、データをコンテナの外部に保存する「データ永続化」という仕組みが必要になります。 データ永続化の方法（Docker Volumeの利用） Docker Volumeは、コンテナ内部のデータを保持するために、コンテナ外部の場所(ディレクトリ)にデータを保管する仕組みです。 コンテナ内のデータは、コンテナを削除すると失われてしまいますが、Docker Volumeはホストマシン上のDockerが管理する領域に作成されます。そのため、コンテナとは別にデータが管理されるのが特徴です。 コンテナ起動時に、このVolumeをコンテナ内の特定のディレクトリに接続（マウント）することで、アプリケーションが書き込むデータはコンテナの外にあるVolumeに保存されます。これにより、コンテナを削除・再作成しても、同じVolumeを再度マウントすれば、データを引き継ぐことができるのです。 DockerでDBを動かすハンズオン 今回のハンズオンはdockerコマンドが使える環境がある方を対象としています。 もし、まだDockerをインストールしていない場合は、以下、公式サイトや記事を参考にして、お使いのUbuntu環境にDocker Engineをセットアップしてください。 【公式サイト】Install Docker Engine on Ubuntu https://docs.docker.com/engine/install/ubuntu/ VSCode Dev ContainerとRancher Desktopで作るコンテナ環境【WSL】 https://tech-lab.sios.jp/archives/33994 実行環境 Ubuntuのバージョン：24.04.1 LTS Dockerのバージョン：28.1.1 DBコンテナイメージの取得 ハンズオンを始めるにあたって、まずはお好きな場所に作業用のディレクトリを作成し、そこに移動してください。今回はMySQL8.4のコンテナイメージを使用します。以下のコマンドでMySQL8.4のDockerイメージを取得できます。 docker pull mysql:8.4 ボリュームの作成 docker volume create コマンドを使うとDocker Volumeを作成できます。 docker volume create <作成したいVolume名> Docker Volumeの作成 作成したDocker Volumeはdocker volume lsコマンドで確認することができます。 docker volume ls Docker Volumeを指定してDBコンテナを起動 docker runコマンドは、オプションを追加することで、コンテナの名前や使用するボリュームなど様々な設定をその場で指定できます。以下は今回使用したコマンドの解説です。 docker run -d dockerコンテナを起動するコマンドdocker runに-dオプションを付けて実行します。-dオプションを使用することでdocker runをバックグラウンド(デタッチモード)で実行することができます。バックグラウンドで実行することでターミナル画面がデータベースのログで埋め尽くされ、他のコマンドが打てなくなることを防ぎます。 – name <付けたいコンテナ名> 起動するコンテナの名前を決めるオプションです。後でコンテナ名を使用して操作するためここで名前を決めます。 -e MYSQL_ROOT_PASSWORD=<設定したいパスワード>  パスワードを設定するオプションです。MySQLの公式イメージは、起動する際にMYSQL_ROOT_PASSWORDという環境変数がないかを探しに行きます、存在していればその値を管理者（root）ユーザーの初期パスワードとして自動で設定してくれます。 -v <作成したvolume>:/var/lib/mysql  作成したDocker Volumeを、コンテナの中の「/var/lib/mysql」というフォルダに接続（マウント）するオプションです。このオプションをつけることでコンテナ内のMySQLが書き込むデータは、コンテナの外にある安全なボリュームに保存されます。 -p 3306:3306  ホストの3306番ポートと、コンテナの3306番ポートを繋ぐオプションです。 mysql:8.4  mysql:8.4という名前のDockerイメージを使って、これらすべての設定を実行します。 docker run -d \ --name <付けたいコンテナ名> \ -e MYSQL_ROOT_PASSWORD=<設定したいパスワード> \ -v <作成したvolume>:/var/lib/mysql \ -p 3306:3306 \ mysql:8.4 このコマンドを実行することでコンテナ起動時にDocker Volumeの指定を出来ます 起動したDBコンテナへのアクセス docker execコマンドは、実行中のDockerコンテナの内部にアクセスし、そこで別のコマンドを実行するためのものです。 今回の目的は、起動したMySQLコンテナにログインすることなので、まずdocker execでコンテナの中に入り、続けてmysqlコマンドを実行します。これにより、コンテナ内でrootユーザーとして、パスワードを使ってMySQLにログインすることができます。 docker exec -it <コンテナ名> mysql -u root -p Enter password: と出力されるので先ほど指定したMySQLのrootユーザーパスワードを入力してEnterを押下するとMySQLにログインできます。 MySQLコンテナにアクセス 永続化の確認 次にコンテナを作り直してもデータが残っていることを確認します。 永続化の確認のため、任意のデータベースを作成し、レコードを追加します。以下は今回データベースやレコードの作成に使用したコマンドです。 CREATE DATABASE <作成するDB名>; USE <作成するDB名>; CREATE TABLE users ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100) NOT NULL ); INSERT INTO users (name) VALUES ('Taro Yamada'); SELECT * FROM <テーブル名>; テストデータを作成 データを作成したのでコンテナを削除します。MySQLコンテナから抜ける際はexitを使用します。 次にコンテナを停止・削除していきます。 docker stop <コンテナ名> を実行してコンテナを停止します。 docker rm <コンテナ名> を実行してコンテナを削除します。 docker stop <コンテナ名>; docker rm <コンテナ名>; コンテナを削除 データ永続化確認のためVolumeを指定してコンテナにアクセスし、テーブル内のデータを確認します。 docker run -d \ --name <任意のコンテナ名> \ -e MYSQL_ROOT_PASSWORD=<任意のパスワード> \ -v <作成したvolume>:/var/lib/mysql \ -p 3306:3306 \ mysql:8.4 docker exec -it <コンテナ名> mysql -u root -p USE <作成するDB名>; SELECT * FROM <テーブル名>; 参考としてVolumeの指定をせずにコンテナを起動しデータを確認するとデータが保存されていないことが確認できます。 Docker Volumeを使用しなかった場合の実行結果 おわりに 今回は、Docker初心者がつまずく「コンテナを消すとデータも消える」という問題を、Docker Volumeを使って解決する方法を紹介しました。 Webアプリなどデータベースを必要とするシステムをコンテナで作成する際、「コンテナが削除されると内部のデータも消える」という性質からデータを守るこの「永続化」の概念はとても重要です。 コンテナとデータを分離するという考え方は、この先Kubernetesを学ぶ上でも非常に重要になってきます。Kubernetesでは、このデータ永続化を、PersistentVolume (PV)と PersistentVolumeClaim(PVC)という、さらに洗練された仕組みで実現します。 次回の記事では、Docker Volumeの知識を土台に、Kubernetesでのデータ管理の世界へステップアップしますので、ぜひご覧ください。 参考文献 辞典・百科事典の検索サービス – Weblio辞書 「永続化の意味・解説」 https://www.weblio.jp/content/%E6%B0%B8%E7%B6%9A%E5%8C%96 Dockerのデータ永続化について https://docker.lock-life.com/archives/341 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post コンテナDB入門シリーズ①：Dockerでデータベースを動かしてみた（MySQL） first appeared on SIOS Tech. Lab .

はじめに Kubernetesを触り始めたばかりで、デプロイや運用は経験したものの、まだ一度もバージョンアップを経験していない方に向けて、「初めてのKubernetesバージョンアップ」という連載をはじめます。バージョンアップにはクラスターのバージョンアップとアプリケーションのバージョンアップの2種類があります。この連載では、ダウンタイムを最小限に抑え、安全にKubernetesの2種類のバージョンアップを行うための手法を解説していきます。 初回となる今回は、デプロイメント戦略の基本と、Kubernetesでの実現方法をアプリケーションのバージョンアップを中心に解説していきます。 デプロイメント戦略の基本 アプリケーションを新しいバージョンに切り替える際、システムの停止時間を最小限にし、リスクをコントロールするために様々なデプロイメント戦略が用いられます。代表的な3つの手法を比較します。 ローリングアップデート 現在稼働している旧バージョンのコンテナを少しずつ停止し、代わりに新バージョンのコンテナを起動していく方法です。 メリット デプロイ中にサービスが停止しません（ダウンタイムがない）。 デメリット 旧バージョンと新バージョンが同時に稼働するため、DBスキーマの変更やAPIの互換性などの違いに注意が必要です。問題があった場合、ロールバックに時間がかかることがあります。Kubernetesの標準的なDeploymentリソースで簡単に実現できます。 Blue/Greenデプロイ 旧バージョン（Blue環境）と全く同じ構成の新バージョン（Green環境）を用意し、両方を並行稼働させます。Green環境のテストが完了したら、外部からのトラフィックを一斉にGreen環境へ切り替える方法です。 メリット 切り替えが一瞬で完了し、ダウンタイムが短いです。問題があった場合、トラフィックをBlue環境に戻すだけで即座にロールバックできるため、非常に安全性が高いです。 デメリット Blue環境とGreen環境の2倍のリソース（コスト）が必要になります。 カナリアリリース 新バージョンを一部のユーザー（カナリアグループ）にだけ公開し、問題がないことを確認しながら徐々に公開範囲を広げていく方法です。 メリット リスクを最小限に抑えつつ、本番環境で新バージョンの影響を検証できます。 デメリット トラフィックを分割する仕組みが必要で、設定が複雑になります。 ユースケース 各デプロイメント戦略がどのような状況に適しているかをまとめます。 デプロイメント戦略 適している状況 ローリングアップデート 軽微なバグ修正、互換性の問題が少ないアップデートで最も一般的 Blue/Greenデプロイ Kubernetesのメジャーバージョンアップなど、切り戻しを迅速に行いたい大規模な変更 カナリアリリース 新機能のA/Bテスト、ユーザー影響を慎重に見極めたい場合 Kubernetesでの実現方法 Kubernetesにおいて、Blue/Greenデプロイの核となるのは「トラフィックの切り替え」です。Blue環境とGreen環境を並行稼働させた後、どこでトラフィックの流れを変えるかによって、実現方法が異なります。 ServiceのSelector切り替え 最もシンプルな手法です。 BlueとGreenのアプリケーションをそれぞれ異なるDeploymentでデプロイします。 外部からのアクセスを受けるServiceリソースは、selectorフィールドでBlue環境のPodラベルを指定しておきます。 切り替え時には、このServiceのselectorをGreen環境のPodラベルに書き換えます。 これにより、ServiceのIPアドレスやDNS名は変わらず、バックエンドのPodだけが一瞬でGreen環境に切り替わります。 Ingressによるトラフィック制御 複数のアプリケーションや異なるクラスター全体を対象とする場合に使われます。 IngressやGateway APIを利用し、ホスト名やパスごとにトラフィックをBlue/GreenそれぞれのServiceにルーティングします。 切り替え時は、Ingressの設定を書き換え、ルーティング先をBlueからGreenのServiceに変更します。 ロードバランサー（LB）での切り替え この手法は、KubernetesのクラスターそのものをBlue/Greenで切り替える大規模なバージョンアップに適しています。 Kubernetesクラスターの外にあるロードバランサー（AWS ALB/NLB、GCP Cloud Load Balancingなど）を利用してトラフィックを制御します。 Blue環境とGreen環境のクラスター全体をLBのターゲットグループとして設定します。 切り替え時は、LBの設定を変更し、トラフィックがBlueターゲットグループからGreenターゲットグループに流れるようにします。 まとめ Blue/Greenデプロイ方式は、新旧環境を並行稼働させ、トラフィックの一斉切り替えにより迅速なロールバックを可能にする、安全性に優れた戦略です。 Kubernetesでは主にアプリケーションのバージョンアップの場合はServiceのselector切り替えやIngressを、クラスターのバージョンアップの場合は外部LBを用いて実現できます。 次回は、Blue/Greenデプロイをより安全に行う上で不可欠な「データの扱い」に焦点を当てます。特にステートフルなアプリケーションをバージョンアップする際のデータ移行の課題について深掘りします。 参考文献 https://kubernetes.io/ja/docs/tutorials/kubernetes-basics/update/update-intro/ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 初めてのKubernetesバージョンアップ：Blue/Greenデプロイ方式とは？ first appeared on SIOS Tech. Lab .

こんにちは。サイオステクノロジーの木村です。 mod_auth_openidc は、Apache で OpenID Connect（OIDC）認証を実現するためのモジュールです。 mod_auth_openidc を用いたOIDC認証環境の構築手順について、OpenID Provider として Entra ID を利用する例で記載します。 検証環境 Rocky Linux 9.0 Apache 2.4.62 Entra ID の設定 アプリケーションの登録 1. Azure管理ポータル にサインインします。 2. サイドメニューより Microsoft Entra ID をクリックします。 3. 管理 – アプリの登録 をクリックし、表示された画面にて「＋新規登録」をクリックします。 4. 以下の項目を入力し「登録」をクリックします。 ・名前：任意の名称 ・サポートされているアカウントの種類：シングル テナント ・リダイレクト URI ：Web を選択し、リダイレクトURI（ユーザーが正常に認証またはサインアウトされた後に認証応答 (トークン) を返すときに宛先として受け入れられる URI）を入力 5. アプリが作成されます。「アプリケーション (クライアント）ID」をメモしておきます。 6. 画面上部の「エンドポイント」をクリックして表示された画面の「OpenID Connect メタデータ ドキュメント」をメモしておきます。 7. 管理 – 証明書とシークレット をクリックし、表示された画面にて「＋新しいクライアントシークレット」をクリックします。 8. 任意の説明と期間を入力し、「追加」をクリックします。 9. 値をメモしておきます。 Apache HTTP サーバの構築と設定 インストール 1. Apache のインストールと確認 $ sudo dnf install -y httpd $ httpd -v 2. mod_auth_openidc のインストールと確認 $ sudo dnf install -y epel-release $ sudo dnf update -y $ sudo dnf install -y mod_auth_openidc $ sudo httpd -M | grep auth_openidc auth_openidc_module (shared) と表示されればモジュールがロードされています。 4. Apache の起動と自動起動設定 $ sudo systemctl start httpd $ sudo systemctl enable httpd HTTPSの設定 OpenID Connectでは、データのやり取りにHTTPS通信が必須となるため、ApacheでのHTTPS設定が必要です。 ※ 今回は検証環境のため、自己署名証明書を使用した手順で行います。本番環境では信頼された認証局による正式な証明書をご使用ください。 1. mod_ssl のインストール $ sudo dnf install -y mod_ssl 2. 自己署名証明書の作成 $ sudo openssl req -x509 -nodes -days 365 \ -newkey rsa:2048 \ -keyout /etc/pki/tls/private/example.key \ -out /etc/pki/tls/certs/example.crt Common Name は、サーバのFQDNを入力します。それ以外は任意の値を入力します。 3. Apache の SSL設定 /etc/httpd/conf.d/ssl.conf を編集して作成した証明書と鍵を指定します。 $ sudo vim /etc/httpd/conf.d/ssl.conf <VirtualHost *:443> ServerName [サーバのFQDN] SSLEngine on ・・・(省略)・・・ SSLCertificateFile /etc/pki/tls/certs/example.crt SSLCertificateKeyFile /etc/pki/tls/private/example.key ・・・(省略)・・・ </VirtualHost> 4. HTTP (ポート80) を無効化 or リダイレクト設定 必要に応じで設定を行います。（手順は割愛します） 5. ファイアウォール設定 Rocky Linux 9 では、デフォルトで firewalld が有効化されており、HTTPS が許可されていない場合、外部からのアクセスが制限されます。アクセス可能にするには以下のコマンドを実行します。 $ sudo firewall-cmd --permanent --add-service=https $ sudo firewall-cmd --reload OIDC認証の設定 1. /etc/httpd/conf.d/ssl.conf を編集して、OIDC認証用の設定を追加します。 $ sudo vim /etc/httpd/conf.d/ssl.conf <VirtualHost *:443> ・・・(省略)・・・ OIDCProviderMetadataURL [Entra ID の設定の手順でメモした OpenID Connect メタデータ ドキュメント] OIDCClientID [Entra ID の設定の手順でメモした アプリケーション (クライアント）ID] OIDCClientSecret [Entra ID の設定の手順でメモした クライアントシークレット] OIDCPKCEMethod S256 OIDCResponseType code OIDCScope "openid profile" OIDCSessionInactivityTimeout 300 OIDCSSLValidateServer Off OIDCProviderTokenEndpointAuth client_secret_post OIDCRedirectURI [Entra ID の設定の手順で入力したリダイレクトURI] OIDCCryptoPassphrase passphrase OIDCRemoteUserClaim preferred_username OIDCPassClaimsAs both OIDCAuthRequestParams prompt=consent <Location /secure> AuthType openid-connect Require valid-user </Location> ・・・(省略)・・・ </VirtualHost> OIDCSSLValidateServer HTTPS で接続する際のサーバー証明書の検証方法 を制御する設定。今回は自己署名証明書を使用しているため Off(検証しない)にしていますが、通常は On に設定します。 OIDCCryptoPassphrase セッション情報やトークン情報を暗号化する際に使用するパスフレーズ。任意の値を指定します。 OIDCRemoteUserClaim 認証後に Apache の REMOTE_USER 環境変数に格納するユーザー識別子（クレーム） を指定する設定。preferred_username を指定すると、IDトークンの preferred_username クレームの値が REMOTE_USER に設定されます。 OIDCPassClaimsAs クレームをアプリケーション環境にどのようにして渡すかの設定。 environment （環境変数）、headers (HTTPヘッダー)、 both （両方）、 none(なし) OIDCAuthRequestParams 認証リクエストを送信する際に追加のパラメータを指定するための設定。 OIDCAuthRequestParams prompt=consent とすると、同意画面が表示されます。同意画面を表示したくない場合は、 prompt=consent の指定は必要ありません。 2. 以下のコマンドで設定を確認します。 $ sudo apachectl configtest Syntax OK と表示されれば問題ありません。 認証後に表示するページの作成 今回はPHPで作成します。 /var/www/html/secure/index.php を以下の内容で作成します。 <?php phpinfo(); ?> 設定の反映 設定を反映するため Apache を再起動します。 $ sudo systemctl restart httpd SELinux で Apache の外部通信を許可 Apache が外部通信できるように設定します。以下のコマンドを実行します。 $ sudo setsebool -P httpd_can_network_connect 1 以上で設定は完了です。 動作確認 OIDC認証できるか確認してみましょう。 1. ブラウザで http://[サーバFQDN]/secure/index.php にアクセスします。 自己署名証明書のため警告画面が表示されますが、詳細を表示 – このWebサイトを閲覧 をクリックして継続します。 2. Entra ID のサインイン画面が表示されますので、Entra ID のユーザー情報を入力しサインインします。 3. 同意画面が表示されるので「承諾」をクリックします。 4. 認証後に表示するページの作成の手順で作成したPHPの設定を表示する画面が表示されます。 認証情報なども表示され確認できます。 参考 リクエストヘッダーで特定の情報のみ渡す方法 OIDCPassClaimsAs を both または　headersに設定すると、認証後に取得したユーザ情報のクレームが全てリクエストヘッダーとして受け渡されます。 全ての情報を受け渡すのではなく、特定のクレームのみ受け渡したい場合は以下のようにします。 <VirtualHost *:443> ・・・(省略)・・・ OIDCPassClaimsAs none ・・・(省略)・・・ <Location /secure> # REMOTE_USER(preferred_username) と name のみヘッダに設定 RequestHeader set X-Remote-User "%{REMOTE_USER}s" RequestHeader set X-Oidc-Name "%{OIDC-CLAIM-name}e" </Location> ・・・(省略)・・・ </VirtualHost> ※ set の後に記載した名称で受け渡されます。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Apache【mod_auth_openidc】×【Entra ID】：OpenID Connect認証でシングルサインオン first appeared on SIOS Tech. Lab .

こんにちは。サイオステクノロジーの木村です。 今回は、mod_auth_basic でBasic認証する手順について記載します。 mod_auth_basic は、Apache HTTP Server におけるBasic認証を実現するモジュールです。検証環境などで、まずは簡易的に認証を導入したい場合などに手軽に利用できる仕組みとして便利です。 以下の手順ではHTTPで説明していますが、通信内容が平文で送信されるためHTTPSを利用するなど注意が必要です。 Apacheのモジュールを使用したOIDC認証について記載した以下の記事もございますので、あわせてご参照ください。 Apache【mod_auth_openidc】×【Entra ID】：OpenID Connect認証でシングルサインオン 検証環境 Rocky Linux 9.0 Apache 2.4.62 手順 Apache のインストールと確認 ・インストール・バージョン確認 $ sudo dnf install -y httpd $ httpd -v ・モジュールの確認 mod_auth_basic は Apache HTTP Server のコアモジュールの一つであり、Apache をインストールすると基本的にデフォルトで含まれます。以下でモジュールがロードされているか確認します。 $ httpd -M | grep auth_basic_module auth_basic_module (shared) と表示されればモジュールがロードされています。 ・Apache の起動と自動起動設定 $ sudo systemctl start httpd $ sudo systemctl enable httpd ブラウザで http://[サーバIP]/ にアクセスし、Apache のデフォルトのテストページが表示されれば、インストールと起動が正常に完了していることを確認できます。 Rocky Linux 9 では、デフォルトで firewalld が有効化されており、HTTP が許可されていない場合、外部からのアクセスが制限されます。アクセス可能にするには以下のコマンドを実行します。（以下は HTTP および HTTPS を許可する場合） $ sudo firewall-cmd --permanent --add-service=http $ sudo firewall-cmd --permanent --add-service=https $ sudo firewall-cmd --reload 認証ファイルの作成 Basic認証で使用するユーザー名とパスワードを格納する「認証ファイル」を作成します。 認証情報はファイル以外にも、LDAP サーバーやデータベースなどと連携して管理することもできます。 ・認証ファイルの作成とユーザ追加 $ sudo htpasswd -c /etc/httpd/.htpasswd [ユーザー名] -c は新規作成を意味します。2人目以降を追加する場合は -c を付けずに実行してください。 コマンドを実行すると、パスワードの入力を求められるので、パスワードを入力します。 ・認証ファイルの確認 $ cat /etc/httpd/.htpasswd 認証後に表示するページの作成 今回はPHPで作成します。 /var/www/html/secure/index.php を以下の内容で作成します。 <?php echo "<h1>Basic認証テスト</h1>"; echo "<p>こんにちは、" . htmlspecialchars($_SERVER['REMOTE_USER']) . " さん.</p>"; ?> Apache 上で PHP を動かすため、モジュールがインストールされていない場合は、以下のコマンドでインストールします。 $ sudo dnf install -y \ php php-cli php-common php-fpm php-mbstring php-xml php-json Basic認証の設定 ・設定ファイルの作成 $ sudo vi /etc/httpd/conf.d/basic-auth.conf 以下の内容を記載し保存します。 <Location "/secure/"> AuthType Basic AuthName "Restricted Area" AuthUserFile /etc/httpd/.htpasswd Require valid-user </Location> ・設定の反映 設定を反映するため Apache を再起動します。 $ sudo systemctl restart httpd 動作確認 ブラウザで http://[サーバIP]/secure/index.php にアクセスします。 ユーザー名とパスワードの入力を求めるダイアログが表示されますので「認証ファイルの作成」の手順で作成したユーザー名とパスワードを入力します。 PHPで作成したページに遷移し、ユーザー名が表示されます。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Apache【mod_auth_basic】でBasic認証 first appeared on SIOS Tech. Lab .

こんな方へ特におすすめ 「自分専用のChatGPT」を作ってみたいと思っている方 RAGやLLM（大規模言語モデル）の具体的な使い方に興味がある方 Pythonとオープンソース技術で、何か面白いものを作りたい開発者 概要 こんにちは。サイオステクノロジーのはらちゃんです！AI相棒の開発ブログ、第一弾へようこそ！ このページでは「 AI相棒 」を、話題の技術 RAG とオープンソースのツールを駆使して開発した軌跡をご紹介します。 APIを使った簡単な方法から、最終的にはPCの中だけで完結する完全ローカル環境の構築まで、試行錯誤の過程をステップバイステップで解説します。この記事を読めば、きっとあなたも自分だけのAI相棒が欲しくなるはずです！ RAGの育て方を試行したブログも執筆予定ですので合わせて覗いてもらえると嬉しいです。 今回の完成イメージです。 コードで最も簡単に開発する方法 ｜LlamaIndex はじめに、今から使う基盤となるものを簡単に紹介します。 LlamaIndex は、RAGシステムを構築することに特化したフレームワークで、非常に直感的かつ少ないコード量で実装できるのが特徴です。 なぜ簡単？ 抽象化 データ読み込み、ベクトル化、保存、検索、LLMとの連携といった複雑な処理を、フレームワークが裏側で自動的にやってくれます。 設定が少ない OpenAIのAPIキーさえあれば、Embeddingモデルやベクトルストアの難しい設定を気にせず始められます。 環境構築が容易 Pythonと数個のライブラリをインストールするだけですぐに試せます。 今回は以下の構成で手軽に実装を試したいと思います。 your_project/ │ ├── data/ │ └── knowledge.txt │ └── app.py Step１：APIでAI相棒を爆速起動 それでは早速作っていきましょう。 何事も、まずは小さく始めるのが成功の秘訣です。最初は、自分のPCに負荷をかけず、無料で使えるAPIサービス Groq を利用して、AI相棒のプロトタイプを作成しました。 準備 LlamaIndex と Groq を連携させるためのライブラリをインストールし、 knowledge.txt というファイルにAI相棒に覚えてほしい情報（今回は架空のプロジェクト情報）を書き込みます。 Bash pip install llama-index openai #ライブラリの追加 pip install llama-index-llms-groq llama-index-embeddings-huggingface APIキーの取得 Groqの公式サイト にサインアップします。 画面左のメニューから「API Keys」を選択します。 「+ Create API Key」ボタンをクリックします。 自分で分かりやすいキーの名前を入力し、作成します。 表示されたAPIキーをコピーします。 このキーは一度しか表示されないため、必ず安全な場所に控えておいてください。 コーディング 驚くことに、コードはたったこれだけです。 LlamaIndex が、データの読み込みからインデックス作成、質問応答までの複雑な処理をすべて裏側でよしなにやってくれます。ポイントは、LLMに Groq を、文章をベクトル化するEmbeddingモデルにオープンソースのものを指定している点です。 「gsk_あなたのGroqのAPIキー」と書かれている部分に先ほど取得したAPIキーを書き込んでください。 app.py import os from llama_index.core import ( VectorStoreIndex, SimpleDirectoryReader, Settings, ) from llama_index.llms.groq import Groq from llama_index.embeddings.huggingface import HuggingFaceEmbedding # 1. GroqのAPIキーを設定 os.environ["GROQ_API_KEY"] = "gsk_あなたのGroqのAPIキー" # 2. LLMをGroqが提供する最新のモデルに変更 Settings.llm = Groq(model="llama-3.1-8b-instant") # 3. EmbeddingモデルをHuggingFaceの無料モデルに設定 Settings.embed_model = HuggingFaceEmbedding( model_name="BAAI/bge-small-en-v1.5" ) # 4. データの読み込み、インデックスの作成、クエリエンジンの構築 print("データを読み込んでいます...") documents = SimpleDirectoryReader("data").load_data() print("インデックスを作成しています...") index = VectorStoreIndex.from_documents( documents, ) print("クエリエンジンを作成しました。質問を入力してください。") query_engine = index.as_query_engine() while True: query = input("質問: ") if query == "exit": break # フレンドリーな口調で答えるよう指示文を付加 friendly_prompt = f"次の質問にフレンドリーな口調で答えて：{query}" response = query_engine.query(friendly_prompt) print("回答:", response) 実行 これだけでもチャットを実行させることができるので、 knowledge.txt を自由に記述して試してみてください。 Bash python app.py このような入力画面が立ち上がれば実行成功です。 knowledge.txt の書き方 AIが情報を効率よく見つけ出せるように、少しだけ書き方を工夫すると性能が上がります。 一つの段落には一つのトピック 関連する情報は近くにまとめて書くと、AIが文脈を理解しやすくなります。 見出しや箇条書きを活用する 人間が読みやすいように情報を整理すると、AIにとっても処理しやすくなります。 「未来の自分は他人」だと思って書く 自分だけが分かるような省略語や暗黙の前提を避け、誰が読んでも分かるように具体的に書くことが重要です。 data/knowledge.txt ## RAG学習用情報テンプレート（仕事用） ### ユーザーのプロフィール - 名前／ニックネーム： - 職業／役割： - 所属部署／チーム： - 得意分野／苦手分野： ### コミュニケーション方針 - 呼び方： - 好ましい対応例： - 避けてほしい対応例： ### よく使う言葉・口癖 - 例： ### 目標・課題 - 現在の目標： - 直面している課題： ### サポートしてほしいこと - 具体的なサポート内容： ### その他メモ - 自由記述： --- ## RAG学習用情報テンプレート（趣味・プライベート用） ### ユーザーのプロフィール - 名前／ニックネーム： - 趣味・関心： - よく行く場所： ### コミュニケーション方針 - 呼び方： - 好ましい対応例： - 避けてほしい対応例： ### よく使う言葉・口癖 - 例： ### 目標・課題 - 現在の目標： - 直面している課題： ### サポートしてほしいこと - 具体的なサポート内容： ### その他メモ - 自由記述： トラブルシューティング 実は、開発中に「指定したモデルは提供終了しました」というエラーに2度も遭遇しました。AIの世界の進化の速さを肌で感じた瞬間です。これは、 Groq の公式サイトで利用可能な最新モデル名を確認し、コードを修正することで簡単に解決できました。 Groqのモデル一覧ページ にアクセスします。 ページに表示されているモデルのリストから、利用したいモデルの「Model ID」をコピーします。 コピーした「Model ID」を、 app.py の Groq(model="...") の部分に貼り付けます。 Step２：Ollamaで完全ローカルなAI相棒へ進化 続いて、APIで手応えを掴んだところで、本命の 「完全ローカル環境」 の構築に挑戦します。これぞオープンソースの醍醐味！インターネットに繋がっていなくても、自分のPCの中だけでAIが動く世界を目指します。 Ollamaのセットアップ Ollama は、様々なオープンソースLLMをコマンド一つで簡単にPCにインストール・実行できる魔法のようなツールです。 公式サイトからインストーラーをダウンロードし、ターミナルで以下のコマンドを実行するだけで、Googleの高性能モデル gemma:7b がPCにインストールされます。 注意点として、WSL環境では ollama serve で手動起動が必要です。現在のターミナルで、以下のコマンドを実行してOllamaサーバーを起動します。 Bash ollama serve 新しいターミナルで、モデル実行コマンドを入力します。 Bash ollama run gemma:7b LlamaIndexとの連携 次に、 app.py のLLM指定部分を、先ほどPCにインストールしたOllamaのモデルに向けるだけです。APIキーの記述はもう必要ありません。 app.py from llama_index.llms.ollama import Ollama # LLMをOllamaで動いているローカルモデルに変更 Settings.llm = Ollama(model="gemma:7b", request_timeout=120.0) 実行 このスクリプトを実行すると、見事に回答が返ってきました。 Bash ollama run gemma:7b このような入力画面が立ち上がれば実行成功です。 まとめ 今回は 「 自分だけのAI相棒作り 」 をしていきました。 LlamaIndex や Ollama といったオープンソースツールのおかげで、専門家でなくても驚くほど簡単にRAGシステムを構築できることがお分かりいただけたかと思います。 APIを使えば、数行のコードで爆速プロトタイピングが可能。 Ollamaを使えば、オフラインで動作するプライベートな環境も実現できる。 このブログが、皆さんの「何か作ってみたい」という気持ちを刺激できたら嬉しいです。まずはこの記事のコードを真似して、あなた自身のメモやブログ記事を読み込ませてみてください。きっと、最高の「AI相棒」が生まれるはずです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post RAGの作り方｜LlamaIndexで簡単2ステップ first appeared on SIOS Tech. Lab .

今号では、nftables で設定可能なオプションや、様々な設定方法について、もう少し深堀りして説明します！ 代表的なオプション -a (もしくは –handle) オプション 前回の記事 でもご説明した通り、ハンドル番号を表示します。 # nft --handle list chain inet table1 chain1 table inet table1 { chain chain1 { # handle 1 type filter hook input priority filter; policy accept; tcp dport 22 accept # handle 2 tcp dport 80 accept # handle 3 } } -f オプション ファイルに記載されたルールセットを読み込みます。 nftabels のルールは nft ファイル に定義します。例えば、 test.nft というファイルに、下記の内容で新たにテーブル、チェーン、ルールを追加するとします。 table inet table2 { chain chain2 { type filter hook input priority filter; policy accept; tcp dport 25 accept } } test.nft を -f オプション を指定して読み込みます。 # nft -f test.nft nft list ruleset コマンドでルールセットを確認してみると、test.nft で指定したテーブル、チェーン、ルールが追加されたことが分かります。 # nft list ruleset table inet table1 { chain chain1 { type filter hook input priority filter; policy accept; tcp dport 22 accept tcp dport 80 accept } } table inet table2 { chain chain2 { type filter hook input priority filter; policy accept; tcp dport 25 accept } } -c オプション nft ファイルの構文が正しいかを確認します。 # nft -c -f test.nft 何らかの構文ミスがあった場合、下記の様に表示されることがあります。 # nft -c -f test.nft ルールの書き方 ルールを設定する際の基本的な構造は、 ①条件 (どんなプロトコルやパケットが対象か) と、 ②処理 (そのパケットをどうするか) となります。 前回の記事 での例を見てみましょう。 # nft add rule inet table1 chain1 tcp dport 22 accept # nft add rule inet table1 chain1 tcp dport 80 accept この場合、 tcp dport が ① 、 22 accept や 80 accept が② になります。 ちなみに、 ①に指定可能なパラメータとしては、下記のようなものがあります。 プロトコルの種類 tcp udp icmp プロトコルに対する詳細な条件 dport 宛先ポート番号 sport 送信元ポート番号 daddr 宛先 IP アドレス saddr 送信元 IP アドレス iif パケットが入ってきたネットワーク機器名 oif パケットが出ていくネットワーク機器名 さらに、 ②に指定可能なパラメータは、下記の通りです。 accept パケットを許可 drop パケットを拒否 (送信元に拒否された旨の通知なし) reject パケットを拒否 (送信元に拒否された旨の通知あり) 一般的な設定例 最後に、これまでの内容を踏まえ、簡単な設定例を 2つご紹介します。 ※あくまで最小限の構成です。必要に応じてルールの追加をしてください。 注意事項 これから紹介する設定例では、複数の条件を指定する必要があるため nft ファイルの形式にて記載しました。 下記の内容を nft 形式のファイルに記載の上 nft -f コマンド でそのファイルを指定し、設定を反映させてください。 nft -f コマンド実行後は、設定を永続化するため systemctl reload nftables を実行してください。 設定例 例1：一般的な Web サーバ ・SSH (22)、HTTP (80)、HTTPS (443) のみを許可 ・上記以外は拒否 table inet server1 { chain input { type filter hook input priority 0; policy drop; # 確立済み・または関連のある通信を許可 (これがないとレスポンスが遮断される) ct state established,related accept # 自分の SSH 接続を許可 tcp dport 22 accept # Web サーバ用のポート (80、443) を許可 tcp dport { 80, 443 } accept # ループバックを許可 iif lo accept } chain forward { type filter hook forward priority 0; policy drop; } chain output { type filter hook output priority 0; policy accept; } } 例2：IP アドレスのブロックリスト ・指定した IP アドレスからのアクセスを拒否 (drop) table inet server2 { chain input { type filter hook input priority 0; policy accept; # ブロックしたい IP アドレス (1つのルールごとに 1つ) ip saddr 192.0.2.10 drop ip saddr 192.0.2.50 drop ip saddr 203.0.113.12 drop } } ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 知っておくとちょっと便利！nftables によるパケットフィルタリング2 first appeared on SIOS Tech. Lab .

こんにちは！ 今月も「OSSのサポートエンジニアが気になった！OSSの最新ニュース」をお届けします。 9/29、アサヒグループホールディングスは社内システムにサイバー攻撃を受けたと発表しました。 アサヒグループHDにサイバー攻撃　ビールなどグループ各社の出荷業務が停止　復旧時期は未定 https://www.itmedia.co.jp/news/articles/2509/29/news144.html 10/14 (米国時間)、「Windows 10 バージョン 22H2」のサポートが終了となりました。 「Windows 10」のサポートが終了 ～最後の「Windows Update」がリリース https://forest.watch.impress.co.jp/docs/news/2054961.html Commodore は、Windows ユーザを対象として自社の無料 OS「Commodore OS Vision 3.0」へ誘導するためのキャンペーンを開始しました。 Commodore、Windows 10 ユーザー救済のため無料 Linux OS を発表 https://biggo.jp/news/202510161732_Commodore_Linux_OS_Windows_10_Alternative ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【2025年10月】OSSサポートエンジニアが気になった！OSS最新ニュース first appeared on SIOS Tech. Lab .

はじめに こんにちは! 参画しているプロジェクトが少し落ち着いてきて余裕が出てきたなーがです。今回はClaude Code UI×Tailscaleで外出先でもセキュアにClaude Codeを使う方法について解説します。 Claude Codeは通常ターミナルベースで動作するため、外出先からスマートフォンやタブレットで利用するのは困難です。しかし、Claude Code UIとTailscaleを組み合わせることで、モバイルデバイスからも安全にClaude Codeにアクセスできるようになります。 今回の設定を行うことで、自宅のPCで動作しているClaude Code UIに、外出先からセキュアにアクセスできるようになります。 Claude Code UIとは Claude Code UIは、Anthropic社のClaude Code CLIをWebブラウザから操作できるオープンソースのGUIツールです。siteboon氏によって開発され、GitHubで公開されています。 Claude Code UIの主な特徴は以下の通りです。 デスクトップ、タブレット、モバイルデバイスでシームレスに動作するレスポンシブデザイン ~/.claude/projects/ から自動的にプロジェクトを検出し、視覚的なプロジェクトブラウザを提供 セッション管理機能により、過去の会話の再開や複数セッションの管理が可能 MCP（Model Context Protocol）サーバーのサポート シンタックスハイライト機能を備えたファイルツリーとライブ編集機能 WebSocketによるリアルタイムストリーミング通信 Claude Code UIは、Node.js環境で動作し、Viteの開発サーバーを使用してローカルで実行されます。これにより、通常はターミナルでしか操作できないClaude Code CLIを、直感的なWebインターフェースから利用できるようになります。 参照: GitHub – siteboon/claudecodeui Claude Code UI公式サイト 既存の方法とセキュリティの課題 Claude Code UIをモバイルから利用する方法として、Cloudflare TunnelやVS Code Serverを使用した例がいくつか公開されています。 【徹底解説】Claude Code UI と Cloudflare Tunnelでスマホから快適にAIコーディング スマホでClaude Code！？外出先でClaude Codeを使ってみた！！ これらの方法でも外出先からのアクセスは実現できますが、 URLを知っていれば誰でもアクセスできてしまう というセキュリティ上の問題があります。開発環境への不正アクセスは、ソースコードの流出やAPI鍵の漏洩など、深刻な被害につながる可能性があります。 そこで今回は、Tailscaleを使用したよりセキュアなアプローチをご紹介します。Tailscaleを利用することで、認証されたデバイスからのみアクセス可能な、真にプライベートなリモート開発環境を構築できます。 Tailscaleとは TailscaleはWireGuardプロトコルをベースとした、P2P型のメッシュVPNサービスです。2019年に元Googleのエンジニアによって設立されたTailscale社が提供しています。 従来のVPNは中央のゲートウェイサーバーを経由する必要があり、トラフィックの集中や単一障害点といった課題がありました。一方、Tailscaleはデバイス間で直接P2P接続を確立するため、これらの課題を解決しています。 Tailscaleの主な特徴は以下の通りです。 WireGuardによるエンドツーエンドの暗号化通信 ゼロトラスト・アーキテクチャによる高いセキュリティ NATやファイアウォールを自動で透過するNAT Traversal機能 GoogleやMicrosoftなどの既存アカウントで簡単にログイン可能 ACL（アクセス制御リスト）による柔軟なアクセス制御 個人利用であれば最大100台のデバイスまで無料で利用可能 Tailscaleは特別なハードウェアやサーバーの構築が不要で、数分でセキュアなプライベートネットワーク（tailnet）を構築できます。また、既存のネットワーク環境に影響を与えないオーバーレイネットワークとして動作するため、段階的な導入が可能です。 参照: What is Tailscale? – Tailscale Docs Tailscaleとは何? 普通のVPNとは何が違う? セットアップ Claude Code UIを実行するPC まずはClaude Code UIの設定から始めます。前回の記事ではClaude Code UIのライブラリをインストールするところまで行ったので、インストールに躓いた方はそちらを参考にしてください。 環境変数を設定します。README.mdに従って .env.example をコピーして .env を作成します。 cp .env.example .env .env ファイルを編集して、必要に応じてポート番号などを設定します。デフォルトでは3001番ポートが使用されます。 アプリケーションを起動します。 npm run dev ブラウザで http://localhost:5173 にアクセスし、Claude Code UIが正常に起動することを確認してください。 次に、PC起動時に自動でClaude Code UIを起動させるためのバッチファイルを作成します。Windows + Rキーを同時押しして下記のコマンドを入力し、OKを押すとスタートアップディレクトリが表示されます。 shell:startup 下記の内容でバッチファイル start-claude-code-ui.bat を作成し、スタートアップディレクトリに配置します。 @echo off cd /d "C:\\Users\\shota\\ws\\claudecodeui" npm run dev pause Tailscaleのインストールと設定 次にTailscaleをインストールして設定を行います。 Tailscale公式サイト からインストーラーをダウンロードして実行します GoogleやMicrosoftなどの任意のアカウントでログインします Windows版の場合、システムトレイにTailscaleのアイコンが表示されます アイコンをクリックして「Connect」ボタンを押し、VPN接続を確立します 接続が成功すると、デバイスにtailnet用のIPアドレス（100.x.x.x形式）が割り当てられます。 tailscale serveの設定 tailscale serve コマンドを実行して、ローカルで動作しているClaude Code UIをTailscaleネットワーク内に公開します。このコマンドを使用すると、開発中のWebアプリケーションをTailscaleネットワーク内の他のデバイスから安全にアクセス可能にできます。 Claude Code UIはViteの開発サーバーで実行されており、デフォルトではポート 5173 で動作しているため、接続先を http://localhost:5173 として指定します。さらに、オプション --bg を使用することで、ターミナルを閉じてもバックグラウンドでサービスが実行され続けるようにします。 tailscale serve --bg <http://localhost:5173> 実行すると、以下のような出力が表示されます。 Available within your tailnet: <https://test-server.tailXXXXXX.ts.net/> |-- proxy <http://localhost:5173> Serve started and running in the background. To disable the proxy, run: tailscale serve --https=443 off この https://test-server.tailXXXXXX.ts.net/ というURLが、Tailscaleネットワーク内からアクセスできるClaude Code UIのアドレスになります。 重要: tailscale serve で公開したサービスは、デフォルトではHTTPSで提供され、Tailscaleが自動的に証明書を発行します。 スマートフォンなど外出先で使用するデバイス Google Play StoreまたはApp StoreからTailscaleアプリをインストールします Google Play Store Apple App Store PC側と同じアカウントでログインします トグルボタンをタップして Connected 状態にします 接続が成功すると、スマートフォンもtailnet内のデバイスとして認識され、PC側で設定したドメイン名でアクセスできるようになります。 Tailscaleのアクセス制御設定 Tailscaleのデフォルト設定では、自分のデバイス間は全て許可されるというポリシーが設定されています。 { "acls": [ // Allow all connections. // Comment this section out if you want to define specific restrictions. {"action": "accept", "src": ["*"], "dst": ["*:*"]}, ], } しかし、セキュリティを強化するために、ACLを設定してアクセスできるデバイスを制限することをお勧めします。 ACLの設定手順 Tailscale管理コンソール にログインします Access controls から Tags を選択して + Create tag をクリックします 以下の2つのタグを作成します tag:server – Claude Code UIを実行するPC用 tag:client – 外出先で使用するデバイス用 General access rules セクションから + Add rule をクリックして、以下のようなアクセスルールを作成します このルールは「 tag:client を持つデバイスのみが tag:server を持つデバイスにアクセスできる」という意味になります。 Machines ページから各デバイスの設定を開き、適切なタグを割り当てます Claude Code UIを実行するPCに tag:server を設定 スマートフォンなど外出先で使用するデバイスに tag:client を設定 これで tag:client を設定したデバイスからのみ、Claude Code UIにアクセスできるようになりました。 アクセスの確認 スマートフォンのブラウザから、先ほど tailscale serve で表示されたドメイン名にアクセスします。 https://test-server.tailXXXXXX.ts.net/ セキュリティのポイント: Claude Code UIのWebインターフェースが表示されれば、設定は成功です。外出先からでも、自宅のPCで動作しているClaude Codeをセキュアに利用できるようになりました。 Tailscaleの通信は全てWireGuardによってエンドツーエンドで暗号化されています インターネットに直接サービスを公開する必要がなく、Tailscaleネットワーク内でのみアクセス可能です ACLによって、アクセス可能なデバイスを明示的に制限できます ポートフォワーディングやファイアウォールの設定変更が不要です おわりに 今回は、Claude Code UI×Tailscaleで外出先でもセキュアにClaude Codeを使う方法について解説しました。 Tailscaleの簡単なセットアップと強力なセキュリティ機能により、複雑なネットワーク設定なしにリモートアクセス環境を構築できます。 tailscale serve コマンド一つで、開発環境に対してセキュアにアクセスできるシンプルさが魅力です。 Claude Code UIとTailscaleを組み合わせることで、通勤中や外出先からでも、スマートフォンやタブレットを使ってAI支援コーディング環境にアクセスできるようになります。ぜひこの設定を活用して、より柔軟な開発スタイルを実現してみてください。 今回の設定内容については、Tailscaleの公式ドキュメントや Claude Code UI公式サイト も参考にしてください。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude Code UI×Tailscaleで外出先でもセキュアにClaude Codeを使おう! first appeared on SIOS Tech. Lab .

はじめに 前回 はKubeBlocksの解説と他類似OSSDB管理ソリューションの比較を行いました。今回はKubeBlocksでサポートされているDBソリューションについて説明します。 KubeBlokcsがサポートしているDB KubeBlocksとはKubernetesクラスタ上にプライベートなDBaaS（Database as a Service）を構築するためのオープンソース基盤です。多種多様なDBソリューションを統一された方法で管理することができます。 また、KubeBlocksはDB以外にもメッセージキューやストレージシステムに対応しています。 ここではKubeBlocksがサポートしているDBソリューションの説明、そのDBソリューションがどのような場面で利用されるかといったユースケースの説明、KubeBlocksがサポートしているDBの種類について紹介します。 Relational Databases Relational Databases(リレーショナルデータベース)とは データを行と列で構成されるテーブルで整理・格納するデータベースシステムです。リレーショナルデータベースではSQLという言語を使ってデータを操作します。 ユースケース 在庫管理や顧客の情報管理など、一貫性のあるデータの管理、データ同士で連携が必要なシステムで使用できます。 サポート対象DB MySQL：世界で最も広く使われているオープンソースのリレーショナルデータベース MariaDB：MySQLから派生したオープンソースのリレーショナルデータベース PostgreSQL：高機能さと拡張性が特徴のオープンソースのリレーショナルデータベース Vanilla PostgreSQL：カスタマイズしていない素のPostgreSQL　 OrioleDB：PostgreSQLの容量、機能、パフォーマンスを最新のアプローチで向上させるために設計された、新しいストレージエンジン NoSQL NoSQLとは リレーショナルデータベースではないデータベースの総称です。リレーショナルデータベースのような厳格な構造（スキーマ）を緩和することで処理を単純にできるため高速に大量のデータを処理できます。 ユースケース ソーシャルメディアやECサイトなど高速に大量のデータを処理する必要があるシステムに向いています。 サポート対象DB MongoDB：大容量データの保存に使用されるドキュメント指向の NoSQL データベース Redis：高速でオープンソースの、メモリ内のキーバリューデータストア etcd：強力な一貫性のある分散キーバリューストア ZooKeeper：分散システムをまとめる、信頼性の高い集中型サービス OLAP Systems OLAP Systems(オンライン分析処理)とは 複雑なデータベースのクエリを高速に処理する技術の一つです。大量に蓄積されたデータを多角的な視点から素早く分析、集計するために特化したシステム。以下の図は、オンライン分析処理の概念図です。 OLAP Systemsの概念図 ユースケース 売り上げの分析やWebサイトのアクセス解析などのビジネスに関わるリアルタイム性が必要なシステムに向いています。 サポート対象DB Elasticsearch：本番規模のワークロードに最適化されたRESTful検索エンジン ClickHouse：列指向データベース StarRocks：リアルタイム、多次元、高度な同時データ分析が可能な高性能分析データウェアハウス高速な列指向データベース OpenSearch：オープンソースの分散型およびRESTful検索エンジン Distributed SQL Databases Distributed SQL Databases(分散SQLデータベース)とは 複数のサーバー(ノード)にデータを分散した状態で保存する仕組みです。データを分散して保存するが単一のリレーショナルデータベースのように振る舞うことが可能で可用性が高く高負荷の処理に強いという特徴があります。 ユースケース 金融プラットフォームなどの特に高可用性が求められるシステム、ユーザーが世界中にいるグローバルなオンラインサービスなど地理的に広範囲で展開され、一貫性を保つ必要があるシステムに向いています。 サポート対象DB TiDB：MySQL互換の分散データベース OceanBase-CE：C++ で開発された MySQL 互換の分散データベース PolarDB-X：MySQLをベースとした水平スケーリングをサポートするMySQL互換の分散データベース Vector Databases Vector Databases(ベクトルデータベース)とは テキスト、画像、音声などの複雑なデータを「ベクトル」という数値の配列に変換して保管します。意味の近さや類似性に基づいて高速で複合検索をすることができます。以下の図はベクトルデータベースの解説図です。 Vector Databasesの解説図 ユースケース ネットショッピングなどでの類似アイテムの推薦、意味検索など類似性や意味で検索を行うシステムで使用されます。 サポート対象DB Qdrant：ベクトルデータベースおよびベクトル類似性検索エンジン Weaviate：オープンソースのベクトルデータベース Milvus：非常に高速なクラウドネイティブのオープンソースベクトルデータベース Time Series Databases Time Series Databases(時系列データベース)とは 時間の経過とともに記録される時系列データを扱うことに特化したデータベースであり、時間の経過とともに記録されるデータを効率的に管理します。高速な書き込みと、特定の時間範囲での集計・分析処理を効率的に行えるように最適化されています。 ユースケース 需要予測、異常検知など時間ベースの分析が必要なシステムなど様々な分野で使用されています。 サポート対象DB InfluxDB：大規模な時系列データの処理に最適化された専用データベース VictoriaMetrics：監視ソリューションとしての利用に特化した時系列データベース GreptimeDB：スケーラビリティ、分析機能、効率性を重視したオープンソース時系列データベース TDengine：データベース、メッセージキュー、キャッシュ等の機能を統合した産業用IoT向けのデータプラットフォーム Graph Databases Graph Databases(グラフデータベース)とは データをノード（点）とエッジ（線）の集合体（グラフ）として捉えて格納するデータベースです。リレーショナルデータベースでは、テーブル同士の繋がりが増えるほど応答速度が低下します。一方、グラフデータベースは繋がりが増えても応答速度があまり低下しないというメリットがあります。以下の図は、グラフデータベースの概念図です。 Graph Databaseの概念図 ユースケース ソーシャルネットワーク、レコメンデーションなど繋がりがあるデータの検索などに向いています。 サポート対象DB Nebula：数兆のエッジと頂点を持つグラフを保存および処理できるオープンソースのグラフデータベース Message Queues Message Queues(メッセージキュー)とは アプリケーション間でデータを非同期で送受信するための中継役をするデータストレージです。キューがあることでデータを送る側も受け取る側も任意のタイミングで処理を行うことができます。以下の図はメッセージキューの概念図です。 Message Queuesの概念図 ユースケース 非同期処理の実装、マイクロサービス間の疎結合化など、システムの応答性・信頼性などを向上させるために様々な場面で使用されています。 サポート対象ソリューション RabbitMQ：オープンソースの分散イベント ストリーミングプラットフォーム Apache Kafka：信頼性が高いメッセージングおよびストリーミングブローカー Apache Pulsar：オープンソースの分散メッセージングおよびストリーミングプラットフォーム Storage System Storage Systemとは デジタルデータを物理的・論理的に保管、管理するための仕組みや製品全般を差します。 ユースケース データベースやアプリケーションのバックアップ先やAI / 機械学習のデータストレージなど様々なデータの保存や管理に使用されます。 サポート対象ソリューション MinIO：AWS S3互換APIを提供するオブジェクトストレージソリューション おわりに 今回の記事で見てきたように、KubeBlocksでは、多種多様なデータベースを、Kubernetesという共通の基盤の上で、統一された作法で管理することができるのがKubeBlocksの強みです。 KubeBlocksを利用することで開発者はインフラの細かな違いを意識することなく、アプリケーションの要件に最適なデータベースを利用できるようになります。 次回はKubeBlocksの導入としてKubernetes上にDBaaSを構築する手順を解説します。 参考文献 KubeBlocks公式： https://kubeblocks.io/docs/preview/user_docs/overview/supported-addons リレーショナルデータベースとは?メリット・デメリットや活用例を紹介： https://primenumber.com/blog/relational-database NoSQLデータベースとは?メリット・デメリットや活用例を紹介： https://primenumber.com/blog/nosql OLAPとは？特徴や実装方式から他の分析手法との比較も解説： https://primenumber.com/blog/olap OLAPデータベースにおける高速化の技術： https://tech.plaid.co.jp/fundamentals_of_olap_db_technology#%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9%E3%81%AE%E4%BE%8B 分散データベースとは？特徴とメリット・デメリットを解説： https://www.anken-navi.jp/news/work-freelance/distributed-database/ CockroachDB公式サイト： https://www.cockroachlabs.com/ TiDB公式サイト： https://pingcap.co.jp/ メッセージキューの基礎知識と活用方法： https://tech-education-nav.com/contents/educational-materials/backend-development/message-queues-explained Amazon SQSのユースケースとAWSサービスとの連携例： https://qiita.com/kenogi/items/ea6154a0fc3e2d81622b ベクトル・データベースとは： https://www.oracle.com/jp/database/vector-database/ Vector DB 入門： https://zenn.dev/atusi/articles/61b7f95b4df726 【2025年決定版】ベクトルDB完全比較とRAG最新活用： https://arpable.com/artificial-intelligence/rag/vector-database-rag/ 時系列データベースとは? 時系列データの活用例や専用DBの必要性について解説： https://www.ctc-g.co.jp/keys/blog/detail/what-is-a-time-series-database 時系列データベースとは？基本と活用のメリット： https://products.sint.co.jp/siob/blog/time-series-database グラフデータベースとは？RDBとの違いや主要4製品の比較まとめ： https://aerospike.co.jp/blog/what-is-graph-database/ グラフデータベースとは何か　～ネットワーク状のデータ構造から瞬時に情報を検索するDBを解説： https://www.imagazine.co.jp/12805-2/ いまさら聞けない、ストレージとサーバの違い： https://www.netapp.com/ja/blog/server-and-storage/ MinIO公式： https://www.min.io/   ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post KubeBlocksでサポートされるDBの種類を徹底解説！ first appeared on SIOS Tech. Lab .

こんにちは、OSS よろず相談室の鹿島です。 はじめに 今回は、DifyとAmazon Bedrockを連携させて、チャットボットとRAG（検索拡張生成）を構築する手順の4回目、最終回です。 【実践】Dify + Amazon Bedrockで、ゼロからチャットボットと RAG を作る① 【実践】Dify + Amazon Bedrockで、ゼロからチャットボットと RAG を作る② 【実践】Dify + Amazon Bedrockで、ゼロからチャットボットと RAG を作る③ 【実践】Dify + Amazon Bedrockで、ゼロからチャットボットと RAG を作る④ 　←本記事 前回までで、構築したDify環境とAmazon Bedrockを連携させ、チャットボットを作成しました。 今回は、RAGを作ってみます。 DifyのRAGは、PDFやテキストなどの社内文書を知識ベースとしてAIに組み込むことができる機能です。 これにより、AIはインターネット上にない社内情報や専門的な質問にも、正確な根拠を持って回答できるようになります。 　ステップ１ ナレッジを作成する 以下のURLにアクセスします。 http://[DifyをインストールしたマシンのIPアドレス] 【実践】Dify + Amazon Bedrockで、ゼロからチャットボットと RAG を作る① でアカウントを作成してログインしていますので、ホームのページが表示されます。 ①「ナレッジ」②「ナレッジを作成」を選択します。 ステップ2　ナレッジを登録する ナレッジとして登録するサンプルとして、厚生労働省が公開しているモデル就業規則をダウンロードしましょう。 以下のページから「モデル就業規則」のPDF版をダウンロードしてください。 https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/koyou_roudou/roudoukijun/zigyonushi/model/index.html ナレッジのデータソースの選択画面で、①「テキストファイルからインポート」②「テキストファイルをアップロード」を選択します。 ダウンロードしたPDFファイルを選択してアップロードします。最後に「次へ」を選択します。 ステップ3　ナレッジの設定をする はじめに、チャンクの設定をします。 チャンク とは、RAG（検索拡張生成）において、AIが扱いやすいようにドキュメントや知識ベースを分割した小さな情報の塊のことです。 長文をそのままAIに入力すると、重要な情報を見落としたり、処理の負荷が高くなったりする問題が発生します。 このチャンク単位で情報を検索し、質問に関連性の高い部分だけをAIに渡すことで、回答の精度と効率を向上させます。 チャンクの詳細については「 弊社ブログ(チャンキング) 」を参照してください。 ここではデフォルトのまま進めます。 次に「インデックス方法」という選択肢があります。 「経済的」は無料で使用できますが、キーワード検索が中心となります。 今回は、「 【実践】Dify + Amazon Bedrockで、ゼロからチャットボットと RAG を作る② 」で Amazon Bedrockでの設定/本記事で利用するモデル で、RAG用に以下のモデルを有効にしました。 Titan Text Embeddings V2 Rerank 1.0 これらのモデルを活用して高精度な検索を実現するため、今回は「高品質」を選んでみましょう。 高品質を選択すると、「埋め込みモデル」を選択できます。 注意点として、ここの選択肢には、 Amazon Bedrockの設定 で有効にしなかったモデルも表示されます。 有効にしていないモデルを選択すると、ここではエラーになりませんが、後にナレッジベースの作成でエラーになります。 有効にしたモデル、ここでは「amazon.titan-embed-text-v2:0」を選択します。 次に、「検索設定」を選択します。 検索方法には3種類あり、「ベクトル検索」は文章の意味の近さで探し、「全文検索」はキーワードの一致で探します。そして、両方を組み合わせた「ハイブリッド検索」が最も精度が高いとされ、推奨されています。 ここでは推奨の「ハイブリッド検索」を選択します。 検索設定では、「rerankモデル」を選択します。 ここでも、Amazon Bedrockの設定で有効にしなかったモデルも選択肢に表示されますが、有効にしたモデルを選択します。 ここでは、「amazon.rerank-v1:0」を選択します。 最後に「保存して処理」をクリックします。 「ナレッジベースが作成されました」「埋め込みが完了しました」と表示され、緑のチェックが付けば成功です。 なお、先述の通り、Bedrockで有効にしていないモデルを選択すると以下のように、赤く表示されます。 [!]マークにマウスカーソルを合わせると、「 AccessDeniedException: You don't have access to the model with the specified model ID 」と表示され、モデルへのアクセス権がないことが分かります。 処理が成功したら「ドキュメントに移動」を選択します。 以下のように、ステータスが「利用可能」になっていればナレッジの作成は成功です。 なお、検索設定やrerankの詳細については、Dify公式マニュアルもあわせて参照してください。 参考： Dify公式マニュアルー検索方法の指定 ステップ4 チャットボットにナレッジを適用する 【実践】Dify + Amazon Bedrockで、ゼロからチャットボットと RAG を作る③ と同様に、チャットボットを作成しましょう。 チャットボットの設定画面で、コンテキストの「追加」を選択します。 すると、先ほど作成したナレッジが表示されます。 ステップ3で作成したナレッジを選択します。 次に、オーケストレーションのプロンプトを編集します。 今回は以下のように入力してみましょう。 「あなたはコンテキストに基づいて回答するチャットボットです。コンテキストに無い質問には「コンテキストに回答がありません」とのみ回答してください」 と入力しておきます。 設定が完了したら、実際に質問してみましょう。 まずはナレッジに含まれる内容について、 「有給休暇について教えて」 と質問します。 すると、アップロードした就業規則のコンテキストに基づいて回答してくれます。 回答の下には根拠となった引用コンテキストが表示され、クリックすると関連度のスコアなどを確認することができます。 次にコンテキストと関係のない質問をします。 「 サンシャインコーストはどこにありますか 」と入力すると、プロンプトの指示通り、まずコンテキストに情報がない旨が表示され、その後にLLM自身の知識から回答が生成されます。 このように、ナレッジ（コンテキスト）がある場合はそれを優先して回答し、ない場合はLLMが直接回答するといった制御が、簡単な設定だけで実現できました。 以上、4回にわたり、DifyとAmazon BedrockのLLMを使用して、RAGアーキテクチャを採用したチャットボットを構築する手順をご紹介しました。 弊社の記述ブログには、Difyに関連する記事が複数ありますので、あわせてご参照ください。 Dify入門ガイド：初心者でもわかる！簡単RAG構築 世界一わかりみの深いDify ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【実践】Dify + Amazon Bedrockで、ゼロからチャットボットと RAG を作る④ first appeared on SIOS Tech. Lab .

はじめに ども！今月はがっつりと開発期間をいただいて、社内で活用できるサービスを作成しつつ、AIとの開発検証を進めている龍ちゃんです。作るものが多くてあっちにフラフラこっちにフラフラって感じです。 今回は、「 Claude Code革命！3フェーズ開発で効率的な開発：計画→実装→検証術 」で提唱した「計画ドキュメント」を用いての開発を3カ月ほど続けたので、そこに対する知見を書いていこうと思います。 結論は「計画ドキュメント」ってめちゃくちゃ大事じゃね？ってお話です。 問題：AIに丸投げすると何が起きるか 技術選定を任せる危険性 開発を進めていく中で、最も課題となったのが「AIに技術選定を委ねてしまう」という問題でした。 具体的な例として、 私はSWRで全ての処理を自動生成しようと試みていました。SWRは本来データフェッチングに特化したライブラリですが、CRUD操作の全てをSWRで解決しようとしていたのです。これは設計思想から考えると適切ではありませんでした。 CRUDの4つの要素のうち、SWRが最適化されているのは主にRead（データ取得）の部分です。Create、Update、Deleteの3/4については本来の用途から外れているにも関わらず、統一性を重視して全てSWRで実装しようとしていました。 人間の開発者であれば「SWRの実装が複雑になるようであれば、素直にAxiosを使用した方が良い」という判断ができます。しかし、AIにはこうした経験に基づく技術的判断や、ライブラリの適切な使い分けに関する感覚が不足しているようです。 龍ちゃん システムプロンプトで「SWRを絶対使うように」って書いていたので、技術選定をしたのは人間なのですがそれに対する課題などの指摘は特にないってのが問題ですね。 AIの限界：誤字脱字と文脈の理解 プロンプトを通じたやり取りで発生する問題も重要な課題でした。 入力に誤字脱字が含まれている場合、AIはそれを修正することなく処理を継続してしまいます。技術用語の誤入力などがあっても、人間であれば文脈から推測して修正できるような内容でも、AIは字面通りに解釈して間違った方向に進んでしまうことがあります。 この結果、想定していたアーキテクチャから逸脱した実装が生成されたり、設計方針に一貫性がなくなったりする問題が発生しました。 具体例として、README.mdに「SWRを必ず使用すること」という記述があったのですが、これが問題の原因となりました。Orvalの設定を適切に調整すれば回避できた問題でしたが、全てのエンドポイントに対してAxiosとSWRの両方のクライアントが生成される状況で、AIは一貫してSWRを選択し続けていました。 根本原因：意思決定の不在 これらの問題の本質は、 人間が行うべき意思決定をAIに委ねてしまっている 点にあります。 人間の開発者は、明文化されていない暗黙知に基づいて技術的判断を行うことがあります。「この技術領域では一般的にこのようなアプローチを取る」といった、体系化されていない経験則や業界標準に関する知識です。 こうした暗黙知は、各開発者の経験や学習によって蓄積されたものですが、現在のAIには十分に備わっていないと感じています。もちろん、私の技術力が不足しているため、AIの能力を十分に引き出せていない可能性もありますが、この差を埋める仕組みが必要です。 その仕組みこそが、 計画ドキュメント による意思決定の明文化なのです。 解決策：計画ドキュメント = 意思決定の場 人間同士の協働 vs AI協働の違い 人間同士での開発とAI協働での開発では、「暗黙知の共有レベル」に大きな差があります。 人間同士での協働の場合： 共通の技術的背景知識を前提とした議論が可能 「一般的にはこのようなアプローチを取る」という共通認識 文脈を理解した柔軟な修正と提案 暗黙の了解による効率的なコミュニケーション AI協働の場合： 明示的に指示された内容のみに基づく判断 技術的なベストプラクティスの理解が限定的 プロンプトの内容に対する忠実な実行 全ての判断基準の明文化が必要 つまり、AI協働においては 全ての意思決定プロセスを文書化 することが不可欠となります。 計画ドキュメントで決めること 計画ドキュメントで明文化すべき要素は、主に以下の4つです： 技術選定： 選定理由とともに、採用しない選択肢（禁則事項）についても記載 ライブラリ間の使い分け基準の明確化 例：SWRはデータフェッチ（Read）操作のみに使用し、CUD操作にはAxiosを使用する アーキテクチャ方針： フロントエンド・バックエンド間の責任境界 エラーハンドリングの統一方針 状態管理の方法と各層の責務 API設計： エンドポイントの命名規則と構造 レスポンス形式の統一ルール エラーレスポンスの標準フォーマット 実装方針： ディレクトリ構成とファイル配置のルール コンポーネント設計のガイドライン テスト方針とカバレッジ基準 意思決定と実行の分離 効果的なAI協働を実現するには、 意思決定フェーズと実行フェーズを明確に分離 することが重要です。 人間の役割： 何を作るか、どのような方針で開発するかを決定する AIの役割： 決定された方針に従って、実際のコードを生成・組み立てる この役割分担により、AIの長所である「高速で大量のコード生成」を活かしながら、人間の「経験に基づく技術判断」を適切に反映できるようになります。 計画の品質が成果物の品質を決定するのは開発の基本原則ですが、特にAI協働においては「計画ドキュメントがプロジェクトの成否を左右する」と言えるでしょう。 実行の標準化：パーツと自動生成 品質保証としてのパーツ化 実際の開発では、意思決定した内容を「パーツ」として標準化することで品質を保証できます。これはソフトウェア工学における品質管理の考え方と共通しています。 システム開発において、個々のコンポーネントの品質がシステム全体に与える影響は重大です。一つのコンポーネントに不具合があると、それがシステム全体の信頼性を損なう可能性があります。プログラムにおいては多少の技術的負債を抱えても稼働し続けることは可能ですが、基盤となるパーツがすべて品質に問題を抱えている場合は、深刻な影響が生じます。 特にフロントエンドを開発する際は、外部のAPIや自作のAPIをパーツとしてとらえることで、作業領域が明確化されます。 人間の役割： 作成すべき機能と要件を明確に定義する 使用するパーツの選択と品質基準の設定 パーツの妥当性と整合性を検証する パーツ/自動生成の役割： 実装方法を標準化し、一貫性を保つ コードの品質を一定レベルに維持する 再利用性を高め、開発効率を向上させる AIの役割： 定義されたパーツを適切に組み合わせて実装する ボイラープレートコードの大量生成を効率化 人間が決定した設計方針に従ってコードを構築する 実例：自動生成パイプライン 具体例として、OpenAPIスペックから型定義を自動同期するパイプラインを構築した際の事例をご紹介します。 // DTO定義（人間による意思決定） interface UserCreateRequest { name: string; email: string; role: 'admin' | 'user'; } // 型定義とAPI関数は自動生成 const createUser = async (data: UserCreateRequest) => { return axios.post<UserResponse>('/api/users', data); }; この実装において重要なポイントは、 DTO定義という設計判断は人間が行い、実行部分（型定義生成、API関数生成）は自動化 している点です。これにより、設計の一貫性を保ちながら実装効率を大幅に向上させることができました。 参考事例：Shadcn/uiのアプローチ Shadcn/uiは、UIコンポーネント開発において「パーツ化」の優れた事例を提供しています。 このライブラリが革新的な点は、UIコンポーネントを標準化された「パーツ」として提供し、開発者が「どのコンポーネントを使用するか」という意思決定に集中できる環境を作り出していることです。AIは「パーツを選択して適切に組み合わせる」という作業に集中でき、結果として開発効率と品質の両立を実現しています。 この考え方は、API接続層やビジネスロジック層にも応用可能であり、AI協働開発における有効なパターンとなり得ると考えています。 実践：意思決定を握る3原則 原則1：計画ドキュメントでの明文化 実施内容： 技術選定の理由を具体的かつ詳細に文書化 実装方針を明確で実行可能なレベルまで記述 暗黙知となっている判断基準の言語化 明文化の範囲について： 理論的にはどこまで詳細化しても構いませんが、コンテキスト量の制約があることを考慮する必要があります。特にClaude等のLLMを使用する場合、トークン制限により詳細すぎる文書は処理できなくなる可能性があります。このバランス調整は現在の技術的制約として受け入れる必要があります。 実践的な運用方法： バックエンドとフロントエンドを並行開発する場合、計画ドキュメントに加えて具体的な実装手順をToDo形式で管理することを推奨します。進捗を可視化することで、AIツールが予期せず停止した場合でも、明確な再開ポイントを確保できます。 原則2：パーツによる実行の標準化 実施内容： 再利用可能なコンポーネント・関数の設計と整備 API接続の標準化（型定義、エラーハンドリング含む） 開発ツール（Linter、Formatter等）の統一と自動化 品質保証の重要性： 個々のパーツの品質は、システム全体の安定性に直結します。不適切な設計のパーツを多数組み合わせると、保守性や拡張性に深刻な問題が生じる可能性があります。そのため、パーツ設計段階での品質基準の設定と検証が不可欠です。 原則3：検証による継続的改善 実施内容： 計画と実装結果の差分分析と記録 発見された問題点や改善点の体系的な蓄積 得られた知見の次回プロジェクトへの適用 現実的な視点の重要性： 完璧な計画ドキュメントや仕様書を最初から作成することは現実的ではありません。開発過程で「より良いアプローチが明確になる」ことは自然な現象です。 そのような状況では、変更の必要性を適切に判断し、修正された方針で実装を完了させることが重要です。完了後には計画と実装の差分を分析し、その経験を将来のプロジェクトに活かすことで、継続的な改善を図ることができます。 まとめ：意思決定は人間、実行はAI 本記事では、3ヶ月間のAI協働開発を通じて得られた実践的な知見をもとに、効果的な協働体制の構築について詳しく解説してきました。 重要ポイントの整理： 技術選定の主導権確保 – AIに技術的判断を委ねることのリスクと、経験に基づく適切な技術選択の重要性 計画ドキュメントによる意思決定の明文化 – 暗黙知の言語化と、全ての判断基準の明確化の必要性 意思決定と実行の明確な分離 – 人間とAIの適切な役割分担による効率化の実現 パーツ化による実行の標準化 – 品質保証と再利用性向上のための設計アプローチ 継続的改善による知見の蓄積 – 完璧性よりも学習と改善を重視したアプローチ 結論として 、現在のAI協働開発においては、 人間が意思決定を行い、AIが実行を担当する という役割分担が最も効果的であると考えられます。 AI技術は急速に進歩していますが、現時点では経験に基づく技術的判断や、コンテキストを考慮した柔軟な意思決定において、人間の能力に及ばない側面があります。一方で、大量のコード生成や、定められたパターンに従った実装作業においては、AIの方が高速かつ正確に処理できます。 この技術特性を理解し、適切な役割分担を実装することで、AI協働開発の真価を発揮することが可能になります。 実践への提案 AI協働開発を検討されている方は、まず「計画ドキュメント」の作成から始めることをお勧めします。初期段階では作成コストが高く感じられるかもしれませんが、中長期的には開発効率と成果物の品質において大幅な改善効果が期待できます。 この記事で紹介した3原則と実践的アプローチが、皆さんのAI協働開発プロジェクトの成功に寄与できれば幸いです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post AI協働開発の落とし穴回避！3ヶ月で実証した計画ドキュメントの価値 first appeared on SIOS Tech. Lab .

初めに ども！今月はAI開発にどっぷりな毎日な龍ちゃんです。今回は「 AIと爆速開発！Next.js×Nest.js型定義同期の自動生成パイプライン構築術 」で開発効率を上げたんですが、そこで起きた問題について原因究明と解決策を模索したので解説していこうと思います。 TL;DR Orvalで全APIエンドポイントにSWRフックを自動生成していたんですが、 バンドルサイズの肥大化 と 不要なオーバーヘッド が問題になってしまいました。 解決策 : client: "axios-functions" に変更して、Axios関数のみを自動生成。SWRは必要な箇所のみカスタムフック実装する方針に切り替えました。 結果 : 47ファイルの移行（4.2時間）で、バンドルサイズを20-30%削減できました！ 問題の発見：便利すぎる自動生成の罠 最初はOrvalで全APIエンドポイントにSWRフックを自動生成する設定にしていました。便利だと思っていたんですよね。型安全だし、統一感もあるし。 でも2ヶ月ほど経った頃、ふと気づいたんです。バンドルサイズはどんどん肥大化していくし、mutation処理は無駄にSWRを経由しているし、コードは複雑になっていく一方。 何かがおかしい。 そこで改めて考え直してみました。SWRって、そもそも何のためのツールだったっけ？と。 SWRの本質を見つめ直す SWRは データ取得（Read）のために設計 されたライブラリです。名前の由来である「stale-while-revalidate」という戦略が示す通り、以下のような特徴があります： キャッシュ戦略による高速な表示 自動再検証（フォーカス時、再接続時など） 複数コンポーネント間でのデータ共有 これって、まさにCRUDのRead（データ取得）に最適化された設計なんですよね。 一方で、 CUD（Create/Update/Delete）はどうでしょうか？ useSWRMutation というフックも用意されていますが、よく考えてみると一回限りのmutationにキャッシュ戦略は不要です。フォーム状態との統合も煩雑になりがちでした。 それなのに、全エンドポイント分のSWRフックを自動生成していたら、本質的には不要なコードが大量に生まれてしまっていたんです。 Before/After: Orval設定の変更 それでは、具体的にどう変更したのか見ていきましょう。 Before（旧設定） output: mode: "split" # ❌ ラッパー関数が生成される client: "swr" # ❌ SWRフック自動生成 # ... 問題点 : 全エンドポイント分のSWRフックが生成され、バンドル肥大化。mutationにも不要なSWRオーバーヘッドが発生していました。 After（新設定） output: mode: "single" # ✅ 直接エクスポート client: "axios-functions" # ✅ Axios関数のみ生成 # ... 改善点 : Axios関数のみを生成し、SWRは必要な箇所のみ手動で作成。バンドルサイズを20-30%削減できました。 シンプルですよね。でも、この変更が大きな効果を生んだんです。 自動生成の3つの問題 実際に移行作業を進めながら、自動生成のどこが問題だったのか明確になってきました。 1. 不要なオーバーヘッド 例えば、投稿を作成する処理を考えてみてください。これって一回限りのアクションですよね。キャッシュも再検証も不要なのに、SWRの状態管理オーバーヘッドが動いている。これは明らかに無駄でした。 2. バンドルサイズの肥大化 数字で見ると、問題の大きさがよくわかります： 項目 Before After 改善 自動生成フック数 41個 0個 完全削除 バンドルサイズ 100% 70-80% 20-30%削減 コード行数 ~2030行 ~800行 約60%削減 全エンドポイント分のSWRフックが生成されて、使わないものも含めて全部バンドルに入ってしまっていたんですね。 3. コンポーネント設計の硬直化 これが一番厄介でした。SWRの状態（ isMutating , error ）とフォームの状態（ isSubmitting , validationErrors ）が分裂してしまって、同期が複雑化していたんです。 実際にフォームを実装していると、「あれ、どっちのエラー状態を見ればいいんだっけ？」みたいなことが頻発していました。 解決策：適材適所のアプローチ そこで、シンプルな方針に切り替えました： ✅ Read（GET） → カスタムSWRフック ✅ CUD（POST/PUT/DELETE） → 直接Axios呼び出し それぞれ見ていきましょう。 パターン1: データ取得（カスタムSWRフック） データ取得には、SWRの恩恵を最大限活用します。 // hooks/useSeriesDrafts.ts import useSWR from "swr"; import { seriesDraftsControllerFindAll } from "@/lib/api/generated"; / シリーズ下書き一覧を取得するカスタムフック SWRのキャッシュ・再検証・データ共有の恩恵を受けられる / export const useSeriesDraftsControllerFindAll = () => { return useSWR("/api/series-drafts", () => seriesDraftsControllerFindAll()); }; // コンポーネントでの使用 const { data, error, isLoading } = useSeriesDraftsControllerFindAll(); SWRのキャッシュ戦略により、複数のコンポーネントで同じデータを効率的に共有できます。フォーカス時の自動再検証なども自動で行われるので、常に新鮮なデータを表示できるんですよね。 パターン2: mutation（直接Axios呼び出し） 一方、データの作成・更新・削除は直接Axiosを呼び出します。 import { useState } from "react"; import { mutate } from "swr"; import { seriesDraftsControllerCreate } from "@/lib/api/generated"; const [isCreating, setIsCreating] = useState(false); / シリーズ下書きを作成する処理 SWRのオーバーヘッドなしで、シンプルに実装できる / const handleCreate = async (data) => { setIsCreating(true); try { await seriesDraftsControllerCreate(data); // 作成後、SWRキャッシュを更新して一覧を再取得 mutate("/api/series-drafts"); } finally { setIsCreating(false); } }; このアプローチなら、不要なオーバーヘッドを回避できて、フォーム状態との統合も容易になります。必要に応じて mutate() でSWRキャッシュを更新すれば、一覧表示も自動的に最新化されます。 シンプルでわかりやすいですよね。 移行中に発見したバグ 実は移行作業中に、思わぬバグも見つかりました。 axiosInstance と axiosClient の混同 : 3つのファイルで axiosClient をAxiosインスタンスとして誤使用していたんです。 // ❌ Before（バグ） import { axiosClient } from "@/lib/axiosClient"; await axiosClient.get("/.auth/me"); // TypeError! // ✅ After（修正） import { axiosInstance } from "@/lib/axiosClient"; await axiosInstance.get("/.auth/me"); 教訓 : axiosClient はOrval mutator関数として使うもので、直接HTTP呼び出しには axiosInstance を使用する必要があります。 命名が似ていると、こういう混同が起きやすいんですよね。移行作業のおかげで、潜在的なバグを早期発見できたのは副次的な効果でした。 移行結果：数字で見る効果 実際の移行結果をまとめてみます。 対象範囲と効果 47ファイル移行完了 （実装時間: 4.2時間、推定14-20時間 → 21-30%効率化） バンドルサイズ20-30%削減 （自動生成フック: 41個 → 0個） カスタムフック : 9個を必要箇所のみ作成 コード行数 : ~2030行 → ~800行（約60%削減） 当初は14-20時間かかると見積もっていたんですが、4.2時間で完了できました。Axiosの関数がパーツとして提供されていたおかげで、AIに実装を任せる際もスムーズに進められたんです。 AI開発を効率化する「パーツ提供」の考え方 今回の経験で実感したのが、 AI開発を効率化する鍵は「パーツを提供する」という考え方 だということです。 shadcn/uiが成功しているのも同じ理由ではないでしょうか。コンポーネントをコピペして、必要に応じてカスタマイズできる。全部を自動生成するのではなく、パーツを提供する。 Axiosのインターフェース部分をパーツとして切り出しておけば、そこに処理を書かせるだけでOK。このアプローチによって、開発効率が飛躍的に向上しました。 フロントエンドとバックエンドの型の齟齬もなくなりましたし、手が止まることも減りました。すっきりとしたコードで実装できるようになったんです。 まとめ：適材適所が長期的な保守性を生む SWRは素晴らしいツールです。でも、すべてのAPI呼び出しに必要なわけではありません。 適材適所のアプローチ : データ取得（Read） : SWRの恩恵を最大限活用 mutation（CUD） : シンプルにAxiosで十分 「便利だから」という理由で全てを自動生成すると、不要な複雑さとバンドル肥大化を招いてしまいます。 Axiosでパーツのみを提供し、SWRは必要な箇所に手動で適用する。この「適材適所」のアプローチが、長期的な保守性と柔軟性を生むんですね。 皆さんも、もし自動生成で「何か複雑になってきたな」と感じたら、一度立ち止まって考えてみてください。本質的に必要なものは何か、ツールの設計思想に沿った使い方ができているか。そこを見直すことで、より良い設計にたどり着けるはずです。 今回の知識を活かして、ぜひ皆さんのプロジェクトでも最適なアプローチを見つけてみてください！ 参考リソース Orval – OpenAPI to TypeScript SWR – React Hooks for Data Fetching 包括的な実装検証ドキュメント ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Orval SWRの自動生成をやめた理由 – SWRの本質を見失っていた話 first appeared on SIOS Tech. Lab .