EastCloudCMS

ブログ

  • AIチャットボットを従来システムの延長で考えると失敗する理由

    AIチャットボットを従来システムの延長で考えると失敗する理由

    はじめに

    AIチャットボットを開発するとき、最初に起きやすいズレは、従来のWebシステムや業務システムと同じ感覚で設計してしまうことである。

    たとえば、入力をできるだけ固定したい、出力形式を厳密に揃えたい、想定シナリオだけを通したいといった発想である。これらは従来システムでは自然な考え方だが、AIチャットボットではそのまま適用すると価値を下げやすい。

    本記事では、AIチャットボットを従来システムの延長で考えると何が起きるのかを設計と品質の観点から整理する。目的は、AIチャットボットを特別視することではなく、従来システムとは異なる判断軸を持つことである。

    AIチャットボットと従来システムの違い

    従来システムは、基本的に「入力」「処理」「出力」を人が定義する。入力条件、分岐、出力結果がある程度固定されているため、仕様とテストが対応しやすい。

    一方、AIチャットボットは自然言語を入力として受け取り、文脈を踏まえて自然言語で返答する。このとき重要なのは、単に答えを返すことではなく、会話の流れの中で意図を読み、必要に応じて問い返しや整理を行う点にある。

    つまり、従来システムが「仕様通りに返す仕組み」に近いのに対し、AIチャットボットは「会話を前に進める仕組み」に近い。この前提を外すと設計も評価もずれていく。

    失敗しやすい設計1：入力を固定しようとする

    従来システムでは、入力を制御するほど品質は安定しやすい。プルダウンやバリデーションはその典型である。

    しかし、AIチャットボットの入力は自然言語である。同じ相談でも、利用者の表現は大きくぶれる。

    たとえば転職相談であれば次のような入力が並ぶ。

    • 退職理由を整理したい
    • 面接で今の会社を辞めたい理由をどう話せばいいかわからない
    • 転職したいが何から考えるべきか迷っている

    ここで「想定した言い回しではないから扱いづらい」と考えると、AIチャットボットの価値を従来システム側へ戻してしまう。本来見るべきなのは入力の揺れそのものではなく、その揺れの中から意図を拾えるかどうかである。

    失敗しやすい設計2：出力を制御しすぎる

    技術者がAIチャットボットを作ると出力形式を強く制御したくなることが多い。項目数を固定する、テンプレートを厳密に決める、構造化出力を前提にするといった設計である。

    もちろん、画面表示や後続処理の都合で一定の整形は必要になる。ただし、対話そのものの品質を上げたい場面で制御を強めすぎると、AIは「考えて返す」のではなく「指定された枠に当てはめて返す」方向に寄りやすい。

    特に曖昧な相談では差が出やすい。利用者がまだ目的を整理できていない段階では、必要なのは整った出力ではなく、状況を分解する問い返しや論点整理である。ここを最初から固定出力に寄せると会話としての柔軟性が落ちる。

    失敗しやすい設計3：想定外の会話を異常系として扱う

    従来システムでは、想定外入力は異常系として扱うことが多い。しかし、AIチャットボットでは想定外の会話が一定数発生すること自体が自然である。

    たとえばFAQ型のチャットボットでも実際には次のような入力が混ざる。

    • 質問が曖昧
    • 途中で相談内容が変わる
    • 事実確認より不安の整理を求めている
    • 質問と感情表現が同時に出る

    このとき「シナリオ外だから失敗」と判断するとAIチャットボットを従来の分岐型システムとして評価していることになる。重要なのは想定外をなくすことではなく、想定外でも会話を破綻させず、目的地へ近づけるかどうかである。

    設計で見るべきものは何か

    AIチャットボットで本当に見るべきなのは、仕様一致ではなく、利用者が目的に近づけたかどうかである。

    実務上は、次の観点で見ると整理しやすい。

    • 利用者の意図を捉えられたか
    • 必要な問い返しができたか
    • 会話が前に進んだか
    • 利用者が次の行動を取りやすくなったか
    • 最終的に満足感を持てたか

    つまり、評価軸は「正しい答えを返したか」だけでは足りない。AIチャットボットでは「会話として成立し、ゴールに向かったか」が重要になる。

    技術者が切り替えるべき視点

    AIチャットボットを扱うとき、技術者は次の視点の切り替えが必要になる。

    従来システムの視点

    • 入力を制御する
    • 出力を固定する
    • 想定外を減らす
    • 正誤で判定する

    AIチャットボットの視点

    • 入力の揺れを受け止める
    • 会話を前進させる
    • 想定外にも対応する
    • ゴール到達で評価する

    この違いを理解しないまま開発すると、実装は進んでも「使われないAIチャットボット」になりやすい。現場で問題になるのは、モデル性能そのものよりも、設計思想と評価軸が従来システムのままになっていることが多い。

    まとめ

    AIチャットボットは、従来システムと同じように扱うほど、強みを出しにくくなる。入力を固定し、出力を縛り、想定外を減らす方向に寄せすぎると、自然言語で思考し会話を進める価値が薄れていく。

    実務で重要なのは、AIチャットボットを「仕様通りに返す仕組み」としてではなく「利用者をゴールへ近づける会話の仕組み」として捉えることである。この前提を置くだけでも、設計・評価・改善の見方は大きく変わる。

  • 【解決】Terraformで「19ce」等のゴミがStateに混入する原因と対策（さくらオブジェクトストレージ / S3互換）

    【解決】Terraformで「19ce」等のゴミがStateに混入する原因と対策（さくらオブジェクトストレージ / S3互換）

    はじめに

    さくらクラウドのオブジェクトストレージなどをTerraformの backend "s3" として利用していると、突如としてStateファイルが破損し、以下のエラーが発生することがあります。

    発生するエラーメッセージ例：

    Error: Failed to load state: Unsupported state file format Error: Decoding state file failed: invalid character '1' looking for beginning of value The state file does not have a "version" attribute.

    これらのエラーが出た際、オブジェクトストレージ上の .tfstate を直接確認すると、ファイルの先頭に 19ce や 1a2b といった謎の16進数が書き込まれている場合があります。

    本記事では、この「チャンク混入問題」の原因と、skip_s3_checksum を使った解決策を解説します。

    原因：S3互換ストレージと「aws-chunked」の不整合

    この現象は、Terraform（AWS SDK）がデータ転送時に使用する aws-chunked（チャンクアップロード） 形式のデータと、S3互換ストレージ側の処理の相性によって発生します。

    本来は通信上の制御情報であるはずの「チャンク長（16進数）」が、ストレージ側で「データ本体の一部」として誤って保存されてしまうのが原因です。

    • 主な発生環境: Terraform v1.5.0 系（SDKの挙動変更により顕著化）
    • 対象ストレージ: さくらオブジェクトストレージ、および一部のS3互換ストレージ

    対策手順：skip_s3_checksum の導入

    この問題を根本的に回避するには、TerraformのBackend設定でチェックサム付与をスキップさせます。

    1. Terraform 本体のアップデート

    まずは、S3互換ストレージとの通信不具合が修正されている Terraform v1.6.6 以上 へのアップグレードを推奨します。

    2. backend 設定の修正

    backend "s3" ブロックに skip_s3_checksum = true を追加します。これが最も重要な対策です。

    Terraform

    terraform {
  backend "s3" {
    bucket   = "your-bucket-name"
    key      = "path/to/terraform.tfstate"
    region   = "ap-northeast-1"
    endpoint = "https://s3.isk01.sakurastorage.jp"

    # --- S3互換ストレージ向けの必須設定 ---
    force_path_style            = true
    skip_credentials_validation = true
    skip_region_validation      = true
    skip_requesting_account_id  = true
    
    # --- 【重要】今回のエラー対策 ---
    skip_s3_checksum            = true
  }
}

    3. 設定の反映

    Bash

    terraform init -reconfigure

    壊れてしまったStateの復旧方法

    すでに先頭に 19ce 等が混入して Unsupported state file format となっている場合、Terraformコマンドからは修復できません。

    1. バージョニングから復元: さくら側のバケットでバージョニングが有効なら、正常だった世代にロールバックするのが最善です。
    2. 手動クリーンアップ: * 該当の .tfstate をダウンロード。
      • テキストエディタ（バイナリエディタ等）で開き、先頭の { より前にある16進数（例: 19ce）を削除。
      • { "version": ... から始まる正しいJSON形式にして保存し、ストレージへ手動で上書きアップロードする。
    3. 再作成（最終手段）: どうしても復旧できない場合は、Stateを削除して terraform import でリソースを紐付け直します。

    まとめ

    さくらオブジェクトストレージで Unsupported state file format が出たら、まずはStateの先頭にゴミが入っていないか確認しましょう。

    対策は 「Terraform 1.6.6+ への更新」と「skip_s3_checksum = true の追加」 です。一度設定しておけば、以降の破損を防ぐことができます。

    よくある質問（Q&A）：Terraform S3 Backend のトラブルシューティング

    Q1. なぜ AWS S3 以外（さくら等）だとこのエラーが出るのですか？

    A. Terraform の標準 S3 Backend は AWS 本家向けに最適化されており、最新の SDK ではデータ整合性を高めるために aws-chunked 形式やチェックサム（SHA256）を付与して送信します。さくらオブジェクトストレージなどの S3互換ストレージ の一部は、この特殊なチャンク形式の解析に完全対応していない場合があり、制御用の16進数（チャンク長）をデータ本体として保存してしまうため、JSON 形式が壊れてしまいます。

    Q2. skip_s3_checksum = true を設定しても安全ですか？

    A. はい、安全です。このオプションは、アップロード時に HTTP ヘッダーにチェックサムを付与する機能をオフにするものですが、通信自体は HTTPS で保護されており、ストレージ側での整合性チェックも従来通り行われるため、実用上のリスクは極めて低いです。むしろ、State が壊れるリスクを避けるために S3互換ストレージ利用時は必須の設定 と言えます。

    Q3. Invalid character '1' looking for beginning of value と出ます。

    A. まさにそれが本件の典型的なエラーメッセージです。State ファイルの 1行目、本来なら {（波括弧）で始まるべき場所に 19ce などの数字（文字 ‘1’ など）が混入していることを示しています。本記事の対策手順に従って Backend 設定を修正し、壊れた State を手動で修復してください。

    Q4. さくら以外の S3互換（MinIO, Cloudflare R2, Wasabi等）でも発生しますか？

    A. 発生する可能性があります。特に独自の API 実装を持つオブジェクトストレージで、Terraform v1.5.x 以降を使用した場合に報告されています。設定に endpoint や force_path_style = true を入れている環境であれば、あわせて skip_s3_checksum = true を入れておくのが定石です。

    Q5. 複数人での開発で State Lock（排他制御）は効きますか？

    A. さくらオブジェクトストレージ単体では、AWS の DynamoDB のような Lock 機能は提供されていません。そのため、複数人で同時に apply すると State が競合するリスクがあります。対策として、Terraform v1.10 以降で導入された use_lockfile = true を試すか、CI/CD（GitHub Actions 等）経由で実行を一本化し、同時実行を防ぐ運用を推奨します。

    Q6. terraform init で HTTP 403 Forbidden や 405 Method Not Allowed が出る場合は？

    A. skip_credentials_validation = true や skip_region_validation = true が抜けていないか確認してください。S3互換ストレージは AWS 固有の認証エンドポイントを持っていないため、これらを true にしないと初期化段階でエラーになることが多いです。

  • さくらのクラウドAppRun 専有型 起動不能ループを脱出せよ！Terraform 構築時の「見えない罠」と復旧ガイド（2026年版）

    さくらのクラウドAppRun 専有型 起動不能ループを脱出せよ！Terraform 構築時の「見えない罠」と復旧ガイド（2026年版）

    さくらインターネットの AppRun Dedicated（専有型）は、自由度が高い反面、Terraform で apply が通っても activeNodeCount=0（Podが1つも立ち上がらない） という事象によく陥ります。

    実案件で特定した「ドキュメントには載っていない仕様」と、復旧のための黄金フローを記録します。

    1. 起動失敗の 9 割を占める「SEG」の疎通不足

    AppRun 専有型のワーカーノードは、デフォルトで外部ネットワークから隔離されています。

    • 罠の正体: ワーカーが起動しても、自身の管理用 コントロールプレーン や、イメージを Pull するための コンテナレジストリ に到達できず、Pod の作成（イメージプル）に失敗します。
    • 解決策: プライベートスイッチ側で SEG (Service Entrance Gateway) を有効化し、以下のエンドポイントを接続先として明示的に許可してください。
      • *.sakuracr.jp（コンテナレジストリ）
      • AppRun 専有型コントロールプレーン
      • （必要なら）オブジェクトストレージ

    2. Terraform のスペック指定（500 Internal Server Error）

    HCL で cpu や memory を定義する際、**「物理的に存在しない組み合わせ」**を指定すると、プロバイダー経由の API 叩き上げ時に 500 エラーで即死します。

    • NG例: cpu = 4, memory = 8 （4vCPU/8GB は存在しない）
    • OK例: cpu = 4, memory = 4 または cpu = 1, memory = 2
    • 復旧のコツ: 起動しない原因がリソース不足か設定ミスかを切り分けるため、まずは 1vCPU / 2GB の最小構成で activeNodeCount=1 を目指すのが鉄則です。

    3. IP Pool の衝突：runner との「1bit」の争い

    ネットワーク設計時、ユーザー用の IP Pool が AppRun のシステムコンポーネント（runner や LB）と重複すると、ASG の作成や割当に失敗します。

    • 罠の正体: frontend の IP pool を .20 開始にすると、内部の管理用 IP と衝突するケースがあります。
    • 解決策: Pool 開始アドレスを .21 以降にずらして設計します。Terraform# 成功パターンの IP Pool 定義例 network_interface { ip_address_pool { start = "10.20.0.21" # .20を避けて開始 end = "10.20.0.29" } }

    4. eth0=shared 時の Default Gateway 制限

    • 症状: ASG 作成時に 400 (defaultGateway must not be set) エラー。
    • 原因: フロントエンド ASG で eth0=shared を使用している場合、他のプライベート NIC に gateway を設定することは仕様上禁止されています。
    • 対策: プライベート側の NIC 定義から gateway 設定を削除してください。

    5. 【最重要】「更新」不可。再作成こそが唯一の反映

    Terraform で ip_address_pool や NIC 設定を書き換えて apply しても、実環境に反映されないことがあります。

    • 理由: 既存の ASG/LB が存在する場合、内部の構築スクリプトが「作成済み」と判定して処理をスキップするためです。
    • 鉄則: 設定変更時は terraform destroy → terraform apply による全削除・再作成が、現状最も確実な反映手段です。

    2026-02-03 最終復旧ログ：正常起動へのチェックリスト

    もし /healthz が 503 を返し続けているなら、以下の順に確認してください。

    1. SEG の有効化: レジストリとコントロールプレーンへの経路があるか？（IP は 10.20.0.5/24 等でセグメント内に存在するか）
    2. リソースの最小化: 1vCPU / 2GB でスケジューリングに成功するか？
    3. DNS 更新: LB 再作成で Public IP が変わっていないか？（salessight.east-cloud.jp の A レコードを新 IP に向け直したか）
    4. 証明書の反映: LB 再作成直後は証明書が一時的に self-signed になるケースがあるため、数分待機してブラウザから確認。

    「Apply は成功するが、中身は死んでいる」 という AppRun Dedicated 特有の挙動を理解すれば、デバッグ時間は劇的に短縮されます。

    AppRun Dedicated 構築トラブルに関するよくある質問（FAQ）

    Q: activeNodeCount が 0 のまま、一向に 1 になりません。何を確認すべきですか？

    A: まずは SEG（Service Entrance Gateway）の設定を確認してください。 専有型ワーカーは、デフォルトで外部ネットワークから遮断されています。SEG で「コンテナレジストリ（*.sakuracr.jp）」および「AppRun専有型コントロールプレーン」への接続許可設定が漏れていると、イメージのプルができず、ノードが活性化しません。

    Q: Terraform でスペック変更（CPU/メモリ）を apply したのに反映されません。

    A: AppRun Dedicated の仕様上、既存リソースの「更新」が効かない項目があります。 特に ASG（Auto Scaling Group）や LB の内部設定は、リソースが存在すると構築スクリプトが処理をスキップする設計になっています。設定変更を確実に反映させるには、一度 terraform destroy でリソースを削除してから再作成（apply）を行ってください。

    Q: ASG 作成時に「500 Internal Server Error」が発生します。原因は何ですか？

    A: 指定したワーカークラス（CPU/メモリの組み合わせ）が実在しない可能性があります。 例えば 4vCPU / 8GB といった組み合わせは提供されていないため、API 側でエラーとなります。4vCPU / 4GB や 2vCPU / 2GB など、さくらインターネットが公式に提供しているスペック表に準じた値を指定してください。

    Q: ロードバランサー（LB）を再作成したらサイトにアクセスできなくなりました。

    A: LB の Public IP アドレスが変更されている可能性があります。 LB を再作成すると、新しい Public IP が割り当てられます。お使いの DNS サービス（さくら外の DNS や A レコード等）にて、salessight.east-cloud.jp などのドメイン向け先を新しい IP アドレスへ手動で更新する必要があります。

    Q: IP Pool の設定で注意すべき「衝突」とは何ですか？

    A: AppRun の管理用コンポーネント（runner）との重複です。 同一セグメント内で .20 付近のアドレスはシステム側で使用されるケースが多いです。ユーザー用の IP Pool 開始アドレスを .21 以降に設定することで、アドレスの奪い合いによる起動失敗を回避できます。

    この記事の内容が、AppRun Dedicated の構築で夜通しデバッグしているエンジニアの助けになれば幸いです。

  • Vercel V0 GitHub連携の落とし穴｜コード同期が壊れる原因と安全な運用方法

    Vercel V0 GitHub連携の落とし穴｜コード同期が壊れる原因と安全な運用方法

    Vercel V0で作ったコードをGitHubと連携すると、コードの同期が崩れるケースがあります。

    以前こちらの記事で、AIと会話しながらUIやアプリを作れるツールとして Vercel V0 を紹介しました。

    ▼参考記事
    プログラム初心者でもコードが書けるAIツールを試してみました

    この記事では、AIと会話しながらアプリやWebサイトを作れる 「バイブコーディング（Vibe Coding）」 の可能性について紹介しました。

    実際にVercel V0は非常に便利なツールなのですが、GitHubと併用したときに

    「コード同期が崩れる」

    という問題にぶつかることがあります。

    今回は

    Vercel V0とGitHubを併用する際のコード同期問題と安全な運用方法

    について紹介します。

    💡この記事はこんな人向け

    • Vercel V0とGitHubを連携して開発したい人
    • AIコーディングツールを実務で使いたい人
    • Vercel V0のコード運用方法を知りたい人

    この記事でわかること

    ✅ Vercel V0とGitHub連携で起きるコード同期問題

    ✅ なぜVercel V0とGit運用が噛み合わないのか

    ✅ AIツールを組み合わせた開発フロー

    ✅ 実務で使えるAI開発運用方法

    先に結論

    Vercel V0を使った開発では、

    Vercel V0 → GitHub → AIコーディングツール

    という開発フローにすると安定します。

    役割は次のように分けるのがおすすめです。

    • Vercel V0：UIや画面の生成
    • GitHub：コード管理
    • Claude Code / Cursor / Codex：リファクタリング・実装
    ポイント
    Vercel V0は「開発ツール」というよりUI生成ツールとして使うと運用が安定します。

    Vercel V0とGitHub連携で起きる問題

    Vercel V0とGitHubを併用すると、次のような問題が発生することがあります。

    • GitHubのコードとVercel V0のコードがズレる
    • AI生成コードが既存コードを上書きする
    • コンフリクトが発生する

    ⚠ よくある詰まり方

    GitHubで修正したコードが、Vercel V0のAI生成によって上書きされてしまうケースがあります。

    なぜコード同期が壊れるのか

    原因はシンプルです。

    Vercel V0はGit履歴ではなく「現在のコード状態」を元にコード生成するからです。

    つまりAIは

    • Git履歴
    • PRレビュー
    • 設計意図

    などを理解しているわけではありません。

    そのためGitHubで管理しているコードと、AIが生成するコードの整合性が崩れることがあります。

    おすすめのAI開発フロー

    この問題を避けるためにおすすめなのが、AIツールを役割分担して使う方法です。

    開発フローは次のようになります。

    1. Vercel V0でUIを生成する
    2. 生成したコードをGitHubに移す
    3. AIコーディングツールでリファクタリングする
    4. GitHubでコード管理する

    ✅ この運用のメリット

    • UI開発を高速化できる
    • AIでコード品質を改善できる
    • Gitで安全にコード管理できる

    AIコーディングツールでコードを仕上げる

    Vercel V0で生成したコードは、そのまま使うよりも

    AIコーディングツールでリファクタリングする

    と品質が大きく向上します。

    例えば次のツールがよく使われます。

    • Claude Code
    • Cursor
    • OpenAI Codex

    これらのツールにGitHubのコードを渡すことで

    • コード整理
    • リファクタリング
    • 機能追加

    などをAIに依頼できます。

    つまり

    Vercel V0はUI生成、AIコーディングツールは実装補助

    という役割分担になります。

    まとめ

    Vercel V0とGitHubを併用する場合は、役割を分けることが重要です。

    • Vercel V0はUI生成ツール
    • GitHubはコード管理ツール
    • AIコーディングツールでコードを仕上げる

    この形にすると、AI開発を安全に進めることができます。

    📌 ひとことで言うと

    Vercel V0でUIを作り、GitHubで管理し、AIコーディングツールでコードを仕上げるとAI開発が安定します。

    Vercel V0チーム開発の落とし穴シリーズ

  • Vercel V0で他人のプロジェクトを編集できない｜Clone Projectで解決する方法

    Vercel V0で他人のプロジェクトを編集できない｜Clone Projectで解決する方法

    他人が作ったプロジェクトでバイブコーディングができない

    以前こちらの記事で、プログラム初心者でもコードが書けるAIツールとして Vercel V0 を紹介しました。

    ▼参考記事
    プログラム初心者でもコードが書けるAIツールを試してみました

    この記事では、AIと会話しながらアプリやWebサイトを作れる 「バイブコーディング（Vibe Coding）」 の可能性について紹介しました。

    実際に私たちもVercel V0を活用して開発を進めているのですが、チームで本番運用をする際にいくつか困った点がありました。

    今回はその1として

    「他人が作ったプロジェクトでバイブコーディングができない問題」

    について紹介します。

    💡この記事はこんな人向け

    • Vercel V0を個人利用からチーム利用に広げたい人
    • Vercel V0でのチーム開発の運用方法を知りたい人
    • AI開発ツールを実務で使う際の注意点を知りたい人

    この記事でわかること

    ✅ Vercel V0で他人のプロジェクトをそのまま編集できない問題

    ✅ Clone Projectを使ったチーム開発の方法

    ✅ Vercel V0をチーム開発で使うための運用ノウハウ

    ✅ 小規模チームでも回しやすい実践的な運用方法

    先に結論

    Vercel V0をチームで使う場合は、Gitのように1つのプロジェクトをそのまま次の人が編集する運用ではなく、

    Clone Projectを使って各メンバーが作業用プロジェクトを持つ

    という形にすると運用が安定します。

    ポイント
    Vercel V0は「1つのプロジェクトをみんなで直接編集する」より、共通プロジェクトをクローンして使うほうがチーム開発では安定します。

    Vercel V0チーム開発で最初に困ること

    Vercel V0をチームで使い始めると、次のような開発の流れを想像する人が多いと思います。

    • メンバーAがVercel V0で画面を作る
    • メンバーBがその続きを編集する
    • 同じプロジェクトでAIに追加指示を出す

    しかし実際の運用では、

    他人が作ったプロジェクトでそのままバイブコーディングを続ける

    という進め方が難しい場面にぶつかります。

    ⚠ よくある詰まり方

    「このプロジェクトの続きを別のメンバーが触ればいい」と考えて進めると、チーム運用で止まりやすくなります。

    解決方法｜Clone Projectを使う

    この問題を解決する方法が、Clone Projectです。

    Clone Projectとは

    既存のプロジェクトをコピーして、自分の作業プロジェクトとして使う方法

    です。

    チーム開発では次の流れにするとスムーズです。

    1. ベースとなるVercel V0プロジェクトを作る
    2. そのプロジェクトをClone Projectする
    3. 各メンバーが自分のクローンで開発する

    ✅ Clone Project運用のメリット

    • 他人のプロジェクトをそのまま触る問題を回避できる
    • 各メンバーが自分の作業環境を持てる
    • AI生成の試行錯誤がしやすい

    Vercel V0をチームで使うならテンプレート運用がおすすめ

    Clone Projectを前提にすると、相性が良いのがテンプレートプロジェクト運用です。

    最初に、チームの共通土台となるプロジェクトを1つ作ります。

    例えば、次のような要素をそろえておくと便利です。

    • 主要画面のたたき台
    • 共通コンポーネント
    • デザインの方向性
    • 命名ルール

    そのテンプレートを各メンバーがCloneして使うことで、チーム開発でも安定した運用ができます。

    ポイント
    Vercel V0は「共有して直接触る」よりも、共通テンプレートを複製して使うほうがチーム運用しやすいです。

    もう一つのおすすめ運用｜日付単位で担当を分ける

    もう一つおすすめなのが、日付単位でVercel V0を触る担当を分ける方法です。

    例えば次のようにします。

    • 月曜日：Aさんが開発
    • 火曜日：Bさんが開発
    • 水曜日：Cさんが開発

    このようにその日にVercel V0を触る人を1人にすることで、チーム運用が安定します。

    💡この運用のメリット

    ✅ 作業の衝突が起きにくい

    ✅ 誰がどこを触ったか分かりやすい

    ✅ 小規模チームでも運用しやすい

    まとめ

    Vercel V0をチーム開発で使う場合は、Gitのような共同編集の感覚で考えないことが重要です。

    • ベースプロジェクトを作る
    • Clone Projectで各メンバーの作業環境を作る
    • テンプレート運用で方向性を統一する
    • 必要に応じて日付単位で担当を分ける
    • コード管理はGitHubで行う

    📌 ひとことで言うと

    Vercel V0は「1つを共有して編集するツール」ではなく、共通プロジェクトをクローンして使うツールとして考えるとチーム開発が安定します。

    Vercel V0チーム開発の落とし穴シリーズ

  • IT補助金を活用した導入事例（2025–2026年版）

    IT補助金を活用した導入事例（2025–2026年版）

    中小企業・小規模事業者が業務改善やDX推進を進めるうえで、IT補助金は2025年以降も重要な支援制度です。本記事では、2025〜2026年にかけてのポイントと、実際の導入事例・効果をわかりやすくまとめています。

    IT補助金とは（2025–2026年版）

    IT補助金は、企業がITツールやクラウドサービスを導入する際、導入費用の一部を国が補助する制度です。特に近年は、業務効率化、デジタル化、セキュリティ強化の3つが重点項目として扱われています。

    • 補助対象：業務管理ツール、クラウドサービス、決済連携、在庫管理、POSなど
    • 補助率：ツール・枠により異なる（例：1/2〜最大3/4）
    • 2025年以降：運用サポート・定着支援を重視する傾向

    2025–2026年の注目ポイント

    • クラウド型ツールの導入優遇
    • セキュリティ対策の強化（ゼロトラストや多要素認証など）
    • 最低賃金付近の事業者向けの特別枠の継続
    • データ活用やAI機能を持つシステムが対象に増加

    【業種別】導入事例（2025–2026年版）

    1. 飲食店：セルフオーダー導入で業務負担を大幅削減

    人手不足に悩んでいた個人経営の飲食店では、タブレット型セルフオーダーを導入。注文ミスが減少し、ピークタイムの対応がスムーズに。結果として客単価アップにもつながりました。

    2. 建設業：現場管理システムで報告・共有が効率化

    従来は紙ベースだった現場日報をクラウド化。写真・進捗・図面がオンラインで共有でき、社内の確認作業が大幅短縮。原価管理の精度も向上しました。

    3. 製造業：生産管理システムでムダを削減

    生産工程や材料の使用量をデジタル管理し、在庫過多・不足の問題を解消。受注から出荷までのリードタイムも短縮されました。

    4. 小売業：POS＋在庫管理で売れ筋が可視化

    売上データと在庫をリアルタイム連携することで、無駄な仕入れが減少。数ヶ月で大幅な在庫最適化を実現しました。

    導入の流れ（2025–2026年版）

    1. 課題の明確化（業務のどこに時間・コストがかかっているか）
    2. IT導入支援事業者へ相談（補助対象ツールの選定）
    3. 申請書類の作成（支援事業者と共同で作成）
    4. 採択後にITツールの導入
    5. 導入効果の報告（事務局へ提出）

    導入時の注意点

    • 対象となるツールは「登録されたものだけ」
    • 補助金は基本的に「後払い方式」
    • 申請後の導入はNG（必ず採択後に契約）
    • 申請書類の内容と実施内容が一致している必要あり

    導入前のチェックリスト

    • 解決したい課題が明確か
    • 導入後の運用担当者を決めているか
    • 補助金の公募スケジュールを把握しているか
    • 必要書類（決算書など）を準備できているか

    まとめ

    2025〜2026年も、IT補助金は中小企業のデジタル化を後押しする重要な制度です。適切なツールを選び、導入後の運用まで見据えることで、業務負荷軽減・売上向上・コスト削減といった具体的な効果が期待できます。

  • GPT-5.4はこうしてリークされた — Codex PR・API・スクリーンショット、3つの漏洩と正式リリースまで

    GPT-5.4はこうしてリークされた — Codex PR・API・スクリーンショット、3つの漏洩と正式リリースまで

    2026年2月末、X上で「alpha-gpt-5.4がパブリックモデルのエンドポイントで発見された」という投稿が広まった。削除されたはずのCodex GitHub PRが本物だとも言われていた。そして1週間後の3月5日、OpenAIはGPT-5.4を正式リリースした。リーク情報はほぼ当たっていた。

    GPT-5.4がどのようにして外に漏れ、実際に何が変わったのかを時系列で整理していく。

    GPT-5.4 概要
    出典: DEV Community

    3つのリーク — 偶然が重なった1週間

    GPT-5.4の存在が外部に出たのは、独立した3つの経路からだ。

    1. Codex GitHub PR（2月27日〜3月2日）

    最初のきっかけは、OpenAIのCodexリポジトリに出されたプルリクエストだった。PR #13050には、画像処理の新機能が必要とするモデルバージョンが (5, 4) と記述されていた。つまりGPT-5.4以降でしか動かない機能が実装されていたことになる。

    このPRで実装されていたのは、detail: original パラメータによる画像圧縮スキップ機能だ。従来のモデルでは送信前に画像が自動的に圧縮・リサイズされていたが、このパラメータを指定するとPNG、JPEG、WebPのオリジナルバイトをそのままモデルに渡すことができる。建築図面や医療画像、UI画面のピクセル単位の分析など、圧縮によって劣化が生じると困るユースケースを想定した機能だ。そしてこの機能がGPT-5.4以降でのみ使えるという記述が、新モデルのビジョン能力が大幅に強化されていることを示していた。

    数時間後、その記述は gpt-5.3-codex or newer に書き換えられた。force pushで履歴も消されたが、スクリーンショットはすでに出回っていた。

    3月2日にはPR #13212でも同じことが起きた。gpt-5.4 をモデル引数に指定した関数呼び出しと、「toggle Fast mode for GPT-5.4」というスラッシュコマンドの記述が含まれていた。削除まで約3時間かかったが、そのころにはキャプチャ済みだった。

    2. モデルセレクターのスクリーンショット

    OpenAIの社員Tiboが、CodexアプリのモデルセレクターUIのスクリーンショットを投稿した。GPT-5.3-Codexの隣にGPT-5.4が並んでいる画面だ。投稿はすぐに削除されたが、魚拓はすでに取られていた。

    3. APIエンドポイント

    alpha-gpt-5.4 というラベルが、公開APIの /models エンドポイントに一時的に現れた。X上で複数ユーザーが確認してスクリーンショットを共有し、それが冒頭の投稿の根拠となった。

    3つとも別々のタイミング、別々の人物によるミスだった。1件なら揉み消せたかもしれないが、3件重なれば確定情報として扱われる。

    正式リリース — 3月5日に何が発表されたか

    リークから1週間後の3月5日、OpenAIはGPT-5.4を正式に発表した。位置づけは「プロフェッショナルワーク向けの、最も高性能かつ効率的なフロンティアモデル」だ。

    スペックとベンチマークをまとめる。

    コンテキストウィンドウ

    API版で100万トークンに対応した。OpenAI史上最大のサイズになる。リーク時には200万トークンという情報も出回っていたが、公式発表では100万トークンに落ち着いた。それでもGPT-5の40万トークンから2.5倍の拡張だ。

    ベンチマーク

    指標GPT-5.2GPT-5.4
    GDPval（知識ワーク）—83%（過去最高）
    投資銀行モデリング68.4%87.3%
    SWE-Bench Pro—57.7%
    OSWorld-Verified47.3%75.0%
    BrowseComp—+17%（GPT-5.2比）

    GPT-5.2と比べて、個々の回答に誤情報が混入する確率が33%減った。レスポンス全体のエラー率も18%下がっている。

    GPT-5.4 Capability Stack
    出典: DEV Community

    Computer-Use（コンピュータ操作）

    GPT-5.4は汎用モデルとして初めて、ネイティブのコンピュータ操作機能を搭載した。アプリケーションをまたいだ複雑なワークフローをAIエージェントが直接実行できる。CodexやAPIと組み合わせれば、マルチステップの自律タスクをそのまま動かせる。

    モデルバリエーション

    3つのバリエーションで展開されている。

    • GPT-5.4：標準版。ChatGPT Plus以上で利用可能
    • GPT-5.4 Thinking：推論に特化。Plus、Team、Proプランで利用可能
    • GPT-5.4 Pro：最高性能。ProおよびEnterpriseプラン限定。BrowseCompで89.3%を記録

    トークン効率

    GPT-5.2と同等の問題解決を、より少ないトークン消費で達成できるようになった。つまりAPI利用者にとっては、性能が上がりながらコストも抑えられるアップデートになる。

    GPT-5.4 Model Selection Map
    出典: DEV Community

    API価格とプラン

    GPT-5.4のトークン単価は、GPT-5.2より改善されている。OpenAI公式の発表では、入力・出力ともにコスト効率が向上しており、API経由で使うコストに対して得られる性能の比率が上がっている。

    Thinking版（GPT-5.4 Thinking）は推論トークンの追加コストがかかる構造だ。ただし複雑なタスクでは推論ステップを挟むことで回答の試行回数が減り、リトライや後処理のコストを含めたトータルが下がるケースもある。単純なQ&AにThinkingを使うのは過剰だが、コードレビューや多段階の計算では費用対効果が出やすい。

    プランごとのアクセス範囲は以下のとおりだ。

    プラン月額GPT-5.4GPT-5.4 ThinkingGPT-5.4 Pro
    Plus$20利用可利用可不可
    Team$30/人利用可利用可不可
    Pro$200利用可利用可利用可
    Enterprise要問合せ利用可利用可利用可

    API経由での利用は、ChatGPTのプランとは別に従量課金として請求される。

    リーク情報はどこまで正確だったか

    冒頭の投稿の主張を振り返ると、こうなる。

    • 「alpha-gpt-5.4がエンドポイントで発見された」→ 事実
    • 「Codex GitHub PRリークは100%本物」→ 事実
    • 「来週早々に登場する」→ ほぼ正確（投稿から5日後にリリース）
    • 「盤面をリセットする世代間飛躍」→ ベンチマーク上は大幅な改善。ただし評価は使う人間次第

    唯一外れたのは、コンテキストウィンドウのサイズだ。リーク時の「200万トークン」に対し、公式では「100万トークン」だった。内部のアルファ版でテストされていたスペックが、リリースまでの間に変更されたと考えるのが自然だろう。

    200万から100万への半減には、いくつかの理由が考えられる。まずレイテンシの問題だ。コンテキストが長くなるほど推論時間が伸びる。GPT-5.4はプロフェッショナルワーク向けのモデルとして位置づけられており、応答速度とのバランスを取った結果、100万トークンに落ち着いた可能性が高い。もう一つは段階リリース戦略だ。200万トークン対応を将来のバージョンに温存し、アップデート時の目玉機能として使うという読み方もできる。

    また、リーク時にはもう一つ噂があった。「会話をまたいで状態を保持するステートフルAI」の実装だ。従来のモデルはセッションごとにリセットされるが、ステートフルモードでは記憶や作業状態を持ち越せる。この機能については、正式発表では触れられなかった。開発中ではあるが、プライバシーとコストの問題を解決できていないため別途発表される可能性が残っている。

    GPT-5シリーズの進化ペース

    GPT-5シリーズは2025年8月の初版リリースから、1〜3ヶ月間隔でアップデートを続けてきた。半年で3回のメジャーアップデートというペースはGPT-4時代より明らかに速い。

    バージョンリリース時期主な進化
    GPT-52025年8月初版。推論能力の飛躍
    GPT-5.22025年11月マルチモーダル強化
    GPT-5.32026年1月Codex統合、エージェント強化
    GPT-5.42026年3月Computer-Use、1Mコンテキスト

    競合他社も同様のペースで動いている。AnthropicはClaude 4.5・4.6を2026年に入って相次いでリリースし、GoogleはGemini 2.5でマルチモーダルと長文コンテキストの性能を引き上げた。三社とも3ヶ月以内のサイクルでフラッグシップモデルを更新しており、AI能力のコモディティ化が加速している局面だ。

    computer-useという機能に絞ると、AnthropicはClaude 3.5の段階から先行して提供していた。OSWorldのベンチマークでも一時期Claudeが上位を占めていた。GPT-5.4はOSWorld-Verifiedで75.0%を記録し、GPT-5.2の47.3%から大幅に向上させた。OpenAIが半年かけてchromecast操作からデスクトップ全体の自動化まで対応域を広げた形で、Anthropicの先行優位は縮まっている。

    開発者への影響

    GPT-5.4のスペック変化は、実際に使う開発者にとって具体的な変化をもたらす。

    1Mトークンのコンテキストウィンドウにより、大規模コードベースの一括分析が現実的になった。従来は分割して投入していたファイル群を、リポジトリごとまとめて渡してアーキテクチャ上の問題点を指摘させるといった使い方が成立する。コンテキスト切れによる情報の断絶を避けられる点は、長いセッションを前提とする開発タスクで特に効いてくる。

    Computer-Useの搭載は、エージェントの自律性を一段引き上げる。ブラウザ操作やGUIアプリへの入力など、これまでAPIでは届かなかった領域を自動化できる。Seleniumや専用スクレイパーを用意しなくても、「このサイトにログインしてデータを取ってきて」という指示をそのまま実行できるようになる。

    Codexとの統合という観点では、PRレビューから修正・テスト実行までの一連のフローを自動化する構成が視野に入る。GPT-5.4はCodexのバックエンドとして動き、コードの意図を読んでレビューコメントを付け、修正案を生成し、テストを走らせて結果を確認する。一人の開発者が抱える反復作業の大部分を委任できる構成だ。

    API利用者にとっては、性能とコストの比率が改善している点がシンプルにうれしい。同じ品質の出力をより少ないトークンで得られるなら、月の請求額を変えずにより多くのタスクをこなせる。

    参考リンク

  • Claude Codeを「チャット」から卒業させる — CLAUDE.md・Skills・Hooksによるプロジェクト構造設計

    Claude Codeを「チャット」から卒業させる — CLAUDE.md・Skills・Hooksによるプロジェクト構造設計

    Claude Codeを使い込んでいくと、ある壁にぶつかる。プロジェクトが大きくなるほど、毎回同じ指示を繰り返す羽目になるのだ。コーディング規約、テストの実行方法、避けてほしいパターン。セッションのたびに伝え直すのは時間の無駄で、ミスの温床にもなる。

    こうした問題への答えとして、海外のエンジニアコミュニティで注目されているのがClaude Codeのプロジェクト構造設計というアプローチだ。単発のプロンプトに頼るのをやめ、ソフトウェアエンジニアリングと同じ発想で仕組みを整える。

    CLAUDE.mdをプロジェクトメモリとして設計する

    CLAUDE.mdは、Claude Codeがセッション開始時に自動で読み込むファイルだ。ここに書いた内容が、すべてのやり取りの前提になる。

    ただのメモ帳として使っている人が多いが、それではもったいない。コーディング規約、アーキテクチャの制約、やってはいけないこと。これらをCLAUDE.mdに一元化すると、セッションごとの指示の繰り返しがなくなる。

    具体的には、こういう内容を入れる。

    ## プロジェクト概要
Tech Stack: Next.js 14, TypeScript, Prisma
DB: PostgreSQL（Supabase）

## 開発コマンド
npm run dev     # 開発サーバー起動
npm run test    # Vitest実行
npm run lint    # ESLint + Prettier

## コーディング規約
- コンポーネントは関数コンポーネント + TypeScript strict
- API routeではzodでバリデーション必須
- main直pushは禁止。必ずブランチを切ってPRを作る

## やってはいけないこと
- anyの使用
- console.logの残存
- テストなしのマージ

    ここで注意したいのが文量だ。Claudeが確実に従えるのは150〜200行程度の指示で、システムプロンプトが約50行を消費するため、実質100〜150行が上限になる。詰め込みすぎると、ランダムに無視される行が出てくる。

    さらにCLAUDE.mdは階層構造に対応している。~/.claude/CLAUDE.mdにはユーザー全体の設定、プロジェクトルートの./CLAUDE.mdにはチーム共通の規約、各ディレクトリにはパッケージ固有のルールを置く。モノレポ構成でも、各パッケージに適切な文脈を渡せる。

    何を書くべきか、書かなくていいか

    CLAUDE.mdに何でも書けばいいわけではない。コンテキストウィンドウには上限があり、読ませる内容が増えるほど各指示の重みが薄まる。判断基準として使えるのが「この行を消したらClaudeがミスするか？」というリトマス試験だ。答えがYesならば書く価値がある。Noならば不要だ。

    書くべき内容

    • ビルドコマンドやテストの実行方法（プロジェクトごとに異なるため）
    • プロジェクト固有のコード規約（チームで決めたルールであり、標準から外れているもの）
    • 環境の癖（特定のライブラリの制約、外部APIの挙動など）
    • アーキテクチャ上の判断（なぜこの設計を選んだかの背景）

    書かなくていい内容

    • Claudeがコードを読めば分かること（ファイル構造、変数名の意味など）
    • 言語・フレームワークの標準的な慣習（TypeScriptの型付け、Reactのhooks規則など）
    • 頻繁に変わる情報（バージョン番号、一時的なTODOなど）

    「プロジェクト固有かどうか」という軸で判断すると迷いにくい。

    Claude Codeのカスタマイズガイド
    出典: alexop.dev

    Skills — 繰り返す作業を機能として定義する

    Claude Codeにはskillsという仕組みがある。.claude/skills/にSKILL.mdファイルを置くと、タスクの文脈に応じて自動的にロードされる。

    コードレビュー、リファクタリング、テスト生成。こうした繰り返しの作業を、毎回アドホックにプロンプトで指示するのではなく、再利用可能なワークフローとして定義する。プロンプトではなく機能として持たせるという発想だ。

    たとえばコードレビュー用のスキルなら、こう書く。

    ---
name: code-review
description: PRのコードレビューを実行する
---

以下の観点でコードをレビューしてください。
1. 型安全性（any, as の使用箇所）
2. エラーハンドリングの網羅性
3. テストカバレッジの十分性
4. パフォーマンス上の懸念
5. セキュリティリスク（インジェクション、XSS）

問題を見つけたら、修正案をコードブロックで提示すること。

    スキルのディレクトリ構造はシンプルだ。.claude/skills/以下にスキル名のフォルダを作り、SKILL.mdを置くだけでよい。

    .claude/skills/
├── code-review/
│   └── SKILL.md
├── test-gen/
│   └── SKILL.md
└── refactor/
    └── SKILL.md

    スキルが増えても整理しやすく、チームメンバーが「どんなスキルが使えるか」を把握しやすい構造になる。

    Slash Commandsとの違いも押さえておきたい。コマンドは/reviewのようにユーザーが明示的に呼び出す。一方スキルは、タスクの文脈からClaude側が判断して読み込む。どちらが合うかはユースケース次第だが、定型的なワークフローほどスキル化の恩恵が出やすい。

    Hooks — 出力の品質を仕組みで担保する

    HooksはClaude Codeのライフサイクルイベントに紐づけてシェルスクリプトを自動実行する仕組みだ。CLAUDE.mdのルールが依頼ベースなら、Hooksは強制に相当する。

    ファイル編集後の自動lint、保護ファイルへの書き込みブロック、特定フォーマットへの変換。手動で毎回直していた整形作業を自動化できる。

    {
  "hooks": {
    "PostToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{
        "type": "command",
        "command": "npx eslint --fix $CLAUDE_FILE_PATH"
      }]
    }]
  }
}

    この設定では、Claudeがファイルを編集するたびにESLintが自動で走る。lint違反が残ったままコミットされる心配がなくなる。

    使えるイベントはPreToolUse、PostToolUse、UserPromptSubmit、SubagentStopなど。実行モードもシェルコマンドとLLM判断の2種類から選べる。

    Claude Codeのフルスタック構成
    出典: alexop.dev

    .claudeignoreとコンテキスト管理

    Claude Codeはデフォルトでプロジェクト全体を走査しようとするが、それがかえってコンテキストを汚染することがある。node_modules/やdist/のようなファイルをClaudeに読ませても意味がない。.claudeignoreファイルでこれらを除外することで、入力トークンを40%以上節約できるケースもある。

    # .claudeignore
node_modules/
dist/
build/
*.min.js
coverage/

    .gitignoreと同じ記法で書けるため、既存の設定を流用しやすい。

    コンテキスト管理には/clearと/compactも活用したい。/clearはセッション間で会話履歴をリセットし、無関係な文脈が引き継がれるのを防ぐ。/compactはコンテキストを要約して圧縮することで、長時間のセッションでもウィンドウ消費を抑える。

    さらに根本的なアプローチとして、サブエージェントによるコンテキスト分離がある。調査タスクを独立したエージェントウィンドウに委任し、結果だけを受け取る形にすると、メインセッションのコンテキストが調査ログで埋まらない。複雑な調査を並行して走らせつつ、メインの会話を軽く保つことができる。

    関心の分離 — ソフトウェア設計と同じ原則

    ここまで紹介した3つの仕組みは、結局ソフトウェアエンジニアリングの基本原則に行き着く。

    レイヤー仕組み性質実行タイミング
    設定CLAUDE.md助言的（advisory）セッション開始時
    機能Skills文脈駆動（contextual）タスク検出時
    実行Hooks強制的（mandatory）イベント発火時

    CLAUDE.mdはClaudeへの「お願い」だ。書かれていれば従うが、忘れられることもある。Skillsはタスクの内容から自動判断して読み込まれる。HooksはClaudeの意思に関係なく、イベントが発火したら必ず実行される。この3つの性質の違いを理解しておくと、どの仕組みを使うべきか判断しやすくなる。

    これにサブエージェントを組み合わせると、セキュリティ監査、テスト実行、コードレビューといった専門タスクを並列で委任できる。各エージェントは独立したコンテキストウィンドウで動くため、メインの会話が汚染されない。

    EastCloudでも、自社プロダクトの開発にClaude Codeを日常的に使っている。CLAUDE.mdでプロジェクトメモリを持ち、スキルでワークフローを定義し、フックで品質を担保する。この三層構造を導入してから、セッションごとの指示の重複が目に見えて減った。また、新しいメンバーがCLAUDE.mdを読むだけでプロジェクトの制約を把握できるため、属人化の防止にもつながっている。

    プロンプトの書き方を磨くだけでは、いずれ限界が来る。AIエージェントによる開発が広がるなか、次に必要なのは仕組みを整えるフェーズだ。

    参考リンク

  • 第3回：さくらのクラウドで構築するモダンアーキテクチャ　GitHub Actions × Self-hosted Runner

    第3回：さくらのクラウドで構築するモダンアーキテクチャ　GitHub Actions × Self-hosted Runner

    GitHub ActionsとSelf-hosted RunnerでVPC内DBにmigrateを実行する方法

    AppRun構成でCI/CDを成立させる実践設計

    📚 さくらのクラウドで作るモダンアーキテクチャ（全5回）

    はじめに

    AppRunを使ったモダン構成で、ほぼ確実にぶつかる問題があります。

    それが

    VPC内部にあるデータベースに、CI/CDからどうやってmigrateを流すか

    という問題です。

    通常のCI/CDでは、

    • GitHub Actions
    • GitLab CI
    • CircleCI

    などのクラウドCIが使われます。

    しかしこれらは インターネット上の環境で実行されるため、VPC内部には直接アクセスできません。

    今回の構成では、

    • データベースはVPC内
    • DBはグローバル公開しない
    • AppRun専有型を利用

    という設計なので、

    CIからDBに直接アクセスすることができません。

    なぜ普通のCIではダメなのか

    構成を整理します。

    GitHub Actions
         ↓
    Internet
         ↓
    AppRun
         ↓
    VPC Router
         ↓
    Database

    ここで問題になるのは

    GitHub ActionsはVPCの外にいる

    という点です。

    つまり、

    • DBを公開しない限り
    • CIはDBに接続できない

    という状態になります。

    しかしDBを公開するのは、セキュリティ的に好ましくありません。

    解決策：Self-hosted Runner

    この問題を解決するのが

    Self-hosted Runner

    です。

    これは簡単に言うと、

    GitHub Actionsの実行環境を自分のサーバーに置く仕組み

    です。

    つまり、

    • RunnerをVPC内に配置
    • GitHub ActionsのジョブをRunnerで実行

    することで、

    CIからVPC内部のリソースにアクセスできるようになります。

    Runner配置の構成

    今回のシリーズでは以下の構成を採用します。

    GitHub Actions
          ↓
    Self-hosted Runner
          ↓
    VPC Router
          ↓
    Database

    RunnerをVPC内部に配置することで、

    • DBアクセス
    • migrate実行
    • 内部API接続

    が可能になります。

    Runnerを配置するセグメント

    第2回で紹介したネットワーク構成を思い出してください。

    VPC
     ├─ public-app-seg
     ├─ private-db-seg
     └─ runner-seg

    Self-hosted Runnerは

    runner-seg

    に配置します。

    理由は以下です。

    • AppRunと役割が異なる
    • DBアクセスを制御しやすい
    • CI用リソースを分離できる

    CI用のサーバーは、必ず専用セグメントに分離するのが安全です。

    Runnerのもう一つの問題：インターネットに出られない

    RunnerをVPC内部に配置すると、もう一つ問題が発生します。

    それは

    Runnerがインターネットに出られない

    という問題です。

    RunnerはCI実行時に以下の通信を行います。

    • GitHub Actions API
    • pip install
    • npm install
    • Docker image pull
    • 外部APIアクセス

    そのため 外向き通信が必須になります。

    NAT VMの役割

    ここで必要になるのが

    NAT VM

    です。

    NAT VMは、

    VPC内部のサーバーがインターネットへ出るための出口

    として機能します。

    構成は以下のようになります。

    Runner
       ↓
    VPC Router
       ↓
    NAT VM
       ↓
    Internet

    RunnerはNAT VMを経由してインターネットへ接続します。

    AWSとの違い

    AWSでは

    • NAT Gateway

    を利用します。

    一方、さくらのクラウドでは

    NATはVMで構築する

    のが一般的です。

    ただしメリットもあります。

    • コストが安い
    • 構成の自由度が高い
    • 通信制御が細かくできる

    NAT VMを含めた全体構成

    最終的なネットワーク構成は以下になります。

    Internet
       ↓
    Cloudflare
       ↓
    AppRun[VPC]
       ├─ public-seg
       │    └─ NAT VM
       │
       ├─ runner-seg
       │    └─ Self-hosted Runner
       │
       └─ private-db-seg
            └─ Database

    通信フロー：

    Runner → NAT VM → Internet → GitHub
    Runner → VPC Router → Database

    この構成により

    • CI/CD
    • VPC内部通信
    • DB保護

    を両立できます。

    Runnerセットアップ

    RunnerはGitHubからスクリプトを取得して起動します。

    mkdir actions-runner
    cd actions-runnercurl -o actions-runner.tar.gz -L https://github.com/actions/runner/releases/latest/download/actions-runner-linux-x64.tar.gztar xzf actions-runner.tar.gz./config.sh --url https://github.com/your-repo --token TOKEN
    ./run.sh

    これでRunnerがGitHubと接続されます。

    GitHub Actions設定例

    Djangoのmigrate実行例です。

    name: migrateon:
      push:
        branches:
          - mainjobs:
      migrate:
        runs-on: self-hosted    steps:
          - uses: actions/checkout@v4      - name: Install dependencies
            run: |
              pip install -r requirements.txt      - name: Run migrate
            run: |
              python manage.py migrate

    重要なのはここです。

    runs-on: self-hosted

    これによりジョブは

    VPC内部のRunner

    で実行されます。

    Runner運用で気をつけること

    Runnerは公開しない

    RunnerはCI実行環境です。

    外部公開すると攻撃対象になります。

    必ずVPC内部に配置します。

    Runnerは専用セグメントに置く

    CI環境は分離します。

    理由：

    • セキュリティ
    • 負荷分離
    • トラブル影響範囲

    Runnerは使い捨ても可能

    高度な構成では

    • Runner自動生成
    • Job終了後削除

    という設計もあります。

    今回はシンプル構成を採用します。

    まとめ

    AppRun構成でCI/CDを成立させるには

    Self-hosted Runner + NAT VM

    が必要になります。

    理由はシンプルです。

    • DBはVPC内部
    • CIはインターネット
    • Runnerは内部
    • Runnerは外に出る必要がある

    だから

    RunnerをVPC内に置き
    NAT VMでインターネットに出る

    この構成が最もシンプルで安全です。

    次回予告

    次回は

    AppRun専有型と共用型の違い

    を解説します。

    ここを理解していないと、

    • VPC接続できない
    • スイッチ接続できない
    • ネットワーク設計が破綻する

    という事故が起きます。

    AppRun設計の核心です。

    よくある質問（FAQ）

    Q1. GitHub ActionsからVPC内のデータベースに接続できますか？

    通常のGitHub Actionsはインターネット上で実行されるため、VPC内部のデータベースには直接接続できません。
    そのため、VPC内にSelf-hosted Runnerを配置し、そのRunner上でCIジョブを実行する構成が必要になります。

    Q2. Self-hosted Runnerとは何ですか？

    Self-hosted Runnerとは、GitHub Actionsのジョブを自分のサーバーで実行できる仕組みです。
    通常はGitHubのクラウド環境でジョブが実行されますが、RunnerをVPC内に配置することで内部リソースへ安全にアクセスできます。

    Q3. Self-hosted Runnerはどこに配置するべきですか？

    Self-hosted Runnerは専用のセグメント（例：runner-seg）に配置するのが推奨です。
    AppRunやデータベースと役割が異なるため、ネットワークを分離することでセキュリティと運用性が向上します。

    Q4. Runnerはインターネットに接続する必要がありますか？

    はい。Runnerは以下の通信を行うため、外向き通信が必要です。

    • GitHub Actions API
    • パッケージダウンロード（pip / npm）
    • Dockerイメージ取得
    • 外部APIアクセス

    そのためVPC内のRunnerはNAT VMなどを経由してインターネットへ接続する必要があります。

    Q5. NAT VMとは何ですか？

    NAT VMとは、VPC内部のサーバーがインターネットへアクセスするための出口となるサーバーです。
    RunnerはNAT VMを経由することで、GitHubやパッケージリポジトリへアクセスできます。

    Q6. AWSの場合はどう構成しますか？

    AWSでは通常、

    • NAT Gateway
    • ECS / EC2 Runner
    • GitHub Actions

    の組み合わせで同様の構成を作ります。
    さくらのクラウドではNAT Gatewayの代わりにNAT VMを構築するケースが多いです。

    Q7. データベースをグローバル公開してCIから接続するのはダメですか？

    可能ではありますが推奨されません。
    DBを公開すると攻撃対象が増えるため、VPC内部に閉じたままSelf-hosted Runner経由で操作する方が安全です。

  • AIは中小企業の業務をどう変える？ — 現場で使える実践ガイド

    AIは中小企業の業務をどう変える？ — 現場で使える実践ガイド

    AI（人工知能）は中小企業の「やること」を劇的に変えます。日常業務の自動化で時間を生み、意思決定をサポートし、顧客体験を向上させます。本記事では、具体的な変化点、導入のメリットと注意点、そして今日から始められるステップを分かりやすく説明します。

    はじめに：なぜ今AIなのか

    クラウドサービスやAPIの普及、低コストのツールが増えたことで、かつては大企業だけの技術だったAIが中小企業にも手の届く存在になりました。重要なのは「最新のAIを入れる」ことではなく、「自社の課題に合ったAIの使い方」を見つけることです。

    中小企業の業務は具体的にどう変わるか

    1. 顧客対応（カスタマーサポート・営業支援）

    チャットボットやメール自動応答で初期問い合わせを自動化。よくある質問はAIが即時対応し、複雑な案件だけ人が担当することで応答スピードと満足度が上がります。営業ではリードのスコアリングや提案資料のドラフト作成をAIが支援します。

    2. 経理・請求・バックオフィス業務の自動化

    領収書や請求書の読み取り（OCR）→自動振り分け→会計ソフトへの入力までをAIで短縮。人的ミスが減り、月次処理の時間が大幅に短縮できます。

    3. 人事・採用・労務管理

    応募者の一次スクリーニング、面接の日程調整、入社手続きの自動案内などのルーチンをAIで処理。採用候補のマッチング精度向上にも貢献します。

    4. マーケティングと販売促進

    顧客データを元にしたパーソナライズ配信や広告の効果予測が容易になります。クリエイティブのA/Bテストやキャッチコピー生成など、アイデア出しの速度も上がります。

    5. 製造・現場業務（該当する場合）

    画像解析による検査、IoTデータからの故障予測、作業進捗の自動記録などは、生産品質と稼働率を改善します。

    導入で期待できるメリット

    • 時間創出：ルーティン作業を自動化し、従業員は付加価値の高い業務に集中できる。
    • コスト削減：外注・残業を減らすことで総コストを圧縮。
    • 意思決定の質向上：データに基づく予測・レポートにより、判断の精度が上がる。
    • 顧客満足の向上：応答速度や提案の精度が改善され、リピートや口コミにつながる。

    導入で注意すべきリスク・課題

    1. データ品質：AIはデータに依存する。正しく整理されていないデータでは誤った結果が出る。
    2. コストとROIの見極め：ツール費用と運用コストを試算し、短期・中期の効果を評価する。
    3. セキュリティと個人情報保護：顧客情報を扱う場合、法令や社内ルールの整備が必須。
    4. 従業員の理解と抵抗：「仕事がなくなる」といった不安を放置しない。教育と業務再設計が必要。

    今日から始められる、実践的な導入ステップ

    1. 業務の棚卸し：まずは時間のかかっている業務、ミスが多い業務、顧客満足に直結する業務を可視化。
    2. 小さく試す（PoC）：一部業務でツールを試用し、効果を短期で検証。成功したら段階的に拡大。
    3. ツール選定：既製品（チャットボット、OCR、CRM連携AI）を優先。自社開発は要件が明確になってから。
    4. 社内教育とルール作り：運用フロー、データ管理ルール、トラブル時の対応手順を整備。
    5. KPI設定と改善：処理時間、顧客応答率、エラー率などの指標を設定し定期的に改善。

    よくある導入パターン（中小企業向け）

    • パターンA（低コスト・短期）：フォーム→チャットボット→FAQ自動応答でカスタマーサポート軽量化。
    • パターンB（業務効率化）：請求書OCR＋会計ソフト連携で経理処理の自動化。
    • パターンC（販売強化）：顧客データ分析＋メール自動配信でリピート率向上。

    導入後の運用で成功させるコツ

    • 最初から完璧を目指さず、小さな勝ち筋を積み重ねる。
    • 定期的に現場の声を吸い上げ、ツールに反映する。
    • ベンダーに頼り切らず、内部で運用できる体制を育てる。

    導入チェックリスト（すぐ使える）

    • 業務フローを可視化したか
    • 自動化の優先順位を決めたか（時間×頻度×影響）
    • 試験運用（PoC）の期間と評価基準を設定したか
    • 個人情報・セキュリティのルールを整備したか
    • 従業員向けの研修計画を用意したか
    • KPIと定期レビューのスケジュールを決めたか

    まとめ：AIは「代替」より「拡張」の道具

    AIは単なるコスト削減ツールではなく、「人の仕事を補完して価値を上げる」力を持っています。中小企業にとって重要なのは、最新技術を追いかけることではなく、自分たちの業務課題を明確にして、効果の出る小さな取り組みから始めることです。まずは一つの業務を自動化してみて、その効果を測ることから始めましょう。