みなさん、こんにちは。ソリューションアーキテクトの 大前 です。9 月に入り一段と涼しくなってきましたが、いかがお過ごしでしょうか。今月は「エージェントに現場を任せるとき、境界線をどこに引くか」をピックアップトピックとしてお届けしつつ、8 月に公開された製造業向けのブログとサービスアップデートをご紹介します。なお、リンク先には英語の記事も含まれていますが、日本語の解説を添えていますのでぜひご覧ください。 ピックアップトピック: エージェントに現場を任せるとき、境界線をどこに引くか PoC では動いたのに本番に載せられない理由の多くは、モデルの精度ではなく「どこまで AI に判断させるか」が決まっていないことにあります。今回ご紹介している記事のいくつかでは、同じ問いに別の角度から答えていました。 AI に判断を任せ、実行は別の層で制御する コニカミノルタ様の「未来の実験室」 では、材料開発の実験を「緑色を作ってください」と自然言語で指示できます。ただしモデルは座標や動作列を生成しません。担当は目標色・操作候補・停止条件へ分解した JSON の中間表現までで、座標制御は人が設計した決定論的な制御層が担います。役割を絞ったので、軽量な Claude Haiku 系でも成立します。 SUMCO 様の SynchroFabAI も同じ構図で、AI に任せるのは「異常状態の推測」と「因果関係の推測」までであり、操作は人間が実施します。 AWS Summit での Physical AI デモ構築 においても、エージェントの権限を「変更できる／人の承認が要る／外で強制される」の 3 段に切ることで安全性を保ちながらロボットが動くデモを構築しました。これらに共通するのは、AI の判断と現実世界への操作を直結させず、その間に人の確認や決定論的な制御、外部から強制される権限制御を置いている点です。 では、どこまでをAIに任せ、どこからを人や制御層に渡すべきでしょうか。その境界は、モデルの性能だけでは決められません。8 月に公表された Amazon Science の論文で提案されている SOP-Bench では、標準作業手順書（SOP）を AI エージェントに実行させて成功率を測定しています。11 のモデルで試した結果、新しいモデルが必ず高い成功率を示すわけではありませんでした。また、ツール構成を比較した実験では、必要なツールだけを与えた場合に比べ、不要なツールを追加すると成功率がほぼ半減しました。自社の手順と実際のツール構成で性能を測り、安定して実行できる範囲だけをAIに委ねることが、AI と人間の境界を決める現実的な方法です。ただし、境界を決めるだけでは十分ではありません。実運用では、その境界を技術的な制約として強制する必要があります。 決めた境界をインフラ側で強制する 8 月は Amazon Bedrock AgentCore にこの方向の機能が 2 つ加わりました。 時間的ポリシー は、それまでの操作履歴を踏まえて各リクエストを評価する認可ルールで、作業順序の強制や特権操作前の人間承認を設定できます。 AgentCore Payments では支払い上限をインフラ層で強制できます。 「危険な操作をしないでください」とプロンプトに書くのと、そもそもその操作が許可されない状態を作るのは、まったく別のことです。後者は OT のインターロックに近い考え方です。エージェントを現場に出すために必要なのは、モデルを賢くすることだけでなく、任せない範囲を先に決め、その境界を外部から強制することなのかもしれません。 直近で開催予定のイベント 9/14 – 9/19 IMTS 2026 北米最大級の工作機械展示会がシカゴで開催されます。AWS もブースを出展予定で、量子コンピューティングと製造業をテーマにした AWS 主催のレセプションもあります。 10/13 – 10/16 CEATEC 2026 JEITA 主催のデジタルイノベーションの総合展示会が幕張メッセで開催されます。テーマは「Transformation -企業が、産業が、そして社会が変わる-」です。 AWS も Hall 4 で、安川電機様とご一緒に展示を予定しています。 10/26 – 10/31 JIMTOF2026 世界最大級の工作機械見本市が東京ビッグサイトで開催されます。 11/30 – 12/4 AWS re:Invent 2026 AWS 最大の学習イベントがラスベガスで開催されます。2,200 を超えるセッションが予定されています。 製造関連ブログのご紹介 8/3 Engineering Development Hub : A unified workbench to accelerate product development 製品開発チームは、 分断されたツール・データサイロ・計算リソース制約 という課題に日々直面しています。 Engineering Development Hub (EDH) は、複雑なシステムの設計・テスト・検証に必要なアプリケーション・計算・データを1つのオープンソース環境に統合した、クラウドベースのエンジニアリングワークベンチです。 Amazon Lab126 や Rivian などの顧客が既にEDHを活用しており、NVIDIA Isaac Sim でのフィジカルAI模倣学習や車載インフォテインメント開発などの実例を紹介しています。 大規模ハードウェア開発を高速化したい設計・開発部門の方におすすめです。 8/6 Run HPC Simulations faster with Siemens Teamcenter and AWS ParallelCluster 「解析の順番待ちで設計が止まる」という課題を、Teamcenter Simulation と AWS ParallelCluster の連携で解いた記事です。設計を選んでジョブを投げれば入力は自動で置かれ、計算ノードは終われば消えます。数日の設計スタディが数時間に。 解析のリードタイム短縮を検討している CAE・解析部門の方におすすめです。 8/7 Leading FMEG Player Builds Manufacturing Control Tower on AWS 工場ごとにデータが閉じていると、異常に気づくのは手遅れになってからとなります。本記事ではインドの大手電設機器メーカーが約 15 工場を 4 層構成でつなぎ、障害後の意思決定を 24 時間超から 2 時間未満に、拠点追加の工数を 1 工場あたり 20% 未満（従来は 80〜100%）に縮めた事例をご紹介しています。 複数拠点の OT データ統合をこれから広げる方におすすめです。 8/18 SUMCO が挑む、Amazon Redshift × 生成 AI による半導体ウェーハ製造 DX 株式会社 SUMCO 様との共著です。ネットワーク分離と権限分離によるセキュアな AWS 基盤上に、データ分析パイプラインの RedPulse と自然言語でのデータ分析を実現する SynchroFabAI を積み上げた道筋が語られます。 セキュリティを担保しつつ、機械学習による品質予測や、品質に強く寄与するパラメータの要因分析などによるデータ分析の力を組織全体に広げていく過程をご覧いただけます。 8/19 Agentic AI でつなぐモノ・サービスの改善サイクル リリース後に溜まる運用データが、次の開発に一度も戻ってこない。その原因を「データのサイロ」と「人材のサイロ」に切り分け、Amazon Quick で埋める方法です。AI 自身が仮説を立てて検証まで進みます。 製品の改善サイクルを回したい開発・品質部門の方におすすめです。 8/20 Amazon Bedrock とロボティクスで目指す「未来の実験室」 コニカミノルタ株式会社様との共著です。材料開発の実験を自然言語で指示すると、ロボットアームが実際に手を動かし、結果が電子実験ノートに戻るという閉ループを約 2 か月で実装されています。開発には Kiro CLI を活用されており、 生成 AI をチャットの外の実機制御へ広げたい研究開発部門の方におすすめです。 8/21 Accelerating Chip Tape-out with AWS Unified Operations 半導体企業がAWS上でEDA（電子設計自動化）ワークロードを実行する際、インフラの可用性・性能がチップ納期に直結します。 AWS Unified Operations はAWSの最上位サポート層にあたり、専任チームが、アーキテクチャ支援・迅速なインシデント対応・財務最適化・セキュリティ監視を提供します。本記事では、12 か月のテープアウト工程に沿って Unified Operations がどのように支援を行うのかを紹介します。 高可用性が求められる HPC ワークロードを抱える方におすすめです。 8/21 SOP-Bench: A new benchmark for evaluating AI agents on real business procedures Amazon Science が発表した、標準作業手順書（SOP）を AI エージェントに実行させる公開ベンチマークです。倉庫点検や危険物分類を含む、12 業務領域・2,000 超のタスクを実際に動くツールと正解付きで用意し、エージェントの。自社の手順を足して評価することもできます。 エージェントを本番に載せる前の物差しが欲しい方におすすめです。 8/24 ソフトウェア開発を AI エージェントで加速する ── TOPPAN が体験した SDLC 主要フェーズの手応え TOPPAN 株式会社様との共著です。20 名が Kiro CLI を活用し、SDLC の Research・Plan・Release をAI と協調しながら回す体験を行いました。レガシーコードから設計書を復元する手応えや、AWS MCP Server を頼りに CI/CD を組む感触が率直に語られます。 AI を活用した開発の効率化に興味のある方におすすめです。 9/1 AWS Summit Japan 2026 Physical AI デモの裏側 Part 1: 企画からステージ制作、アプリケーション開発まで 6 月の Summit で展示した「AI エージェントが街の障害物を自律的に見つけて片付ける」デモを、どう作ったかの記録です。10 名全員が兼務で、実機を使った統合に充てられたのは本番前の約 1 か月という過酷な条件の中で、企画の可視化から 3D モデリング、実装、説明員資料などの全工程を生成 AI と伴走する過程を紹介しています。 AI を使った開発プロセスの型づくりに関心のある方は、ここから読むと全体像がつかめます。 9/1 AWS Summit Japan 2026 Physical AI デモの裏側 Part 2: ロボット開発編 上記デモのロボット側です。FANUC 社製協働ロボット 2 台をクラウドの AI エージェントと連携させるデモ開発の裏側をご紹介しております。画像から動作指令までを 1 つのモデルで出す方式を採らなかった理由、コーディングエージェントの権限を「変更できる／人の承認が要る／エージェントの外で強制される」の 3 つに切った線引き、そして手先の向きを保つ拘束を AI が誤って無効化した経験から「禁止と代替手順はセットで書く」に至った経緯まで、任せる範囲の決め方が具体的に語られます。 今号のピックアップトピックの実例編として、あわせてお読みください。 製造関連の主要なサービスアップデート 8/3 Amazon SageMaker AI がフルファインチューニングに対応 25 以上のオープンソースモデルで全パラメーターを更新できます。設備の型式ごとの符牒や検査基準といった組織固有の語彙を、モデルに深く覚え込ませたいときにご利用いただけます。 8/4 AWS Security Hub Extended がソフトウェアサプライチェーンのセキュリティに対応 外部から取り込むオープンソース部品に悪意あるコードが混ざっていないかを、アプリに組み込む前に検出・遮断できます。 8/6 AgentCore に時系列ポリシーとレート制限を追加 ピックアップトピックでご紹介した機能です。宛先ごとのリクエスト数・トークン数の上限も併せて設定できます。 8/7 AWS Parallel Computing Service が FedRAMP・SOC・ISO・PCI の対象に マネージド HPC サービスである、Parallel Computing Service がSOC、ISO などの主要な第三者認証の対象になりました。統制・監査要件が壁になっていた技術計算部門の導入判断を後押しします。 8/11 AWS Glue から SageMaker Unified Studio へワンクリックでアクセス AWS Glue と同じ権限のままクエリ・品質チェック・パイプライン構築へ移れます。データカタログの整備から分析・AI 活用までを、ツールを行き来せずに進められます。 8/18 AgentCore payments が一般提供開始 エージェントが有料の API を自ら見つけて使い、決済まで行えます。支払い上限はインフラ側で強制されるので、外部データを都度買う調達系エージェントも統制下で運用できます。 8/19 Amazon SageMaker のノートブックが Trusted Identity Propagation に対応 共有ロールではなく利用者本人の ID でデータ参照を制御でき、誰が何を見たかが AWS CloudTrail に残ります。品質データや設計情報の閲覧範囲を部門・拠点で分けたい分析基盤にご利用いただけます。 最後まで読んでいただきありがとうございました。 今月は、AI に任せる範囲の決め方と、その境界を仕組みで守る方法をご紹介しました。来月も、製造業における AI 活用のヒントをお届けします。それでは、また来月お会いしましょう！ 著者について 大前 遼（Ryo Omae） ソリューションアーキテクト 大前 遼（Ryo Omae）は、アマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクトです。製造業のお客様を中心に、クラウド活用の技術支援を行っています。好きな領域は機械学習や生成 AI ・ロボティクスで、最近は Physical AI デモの構築に注力しています。

本ブログは 2026 年 8 月 11 日に公開された Amazon Science Blog “ A decade of mathematical certainty: Reflections on the Automated Reasoning Group ” を翻訳したものです。 Automated Reasoning Group の設立から 10 年。数学的論理は学術研究の領域を越え、お客様の数百万のワークロードを守る本番サービスにまで広がりました。これは、システムが単に「おそらく正しい」だけでなく、「正しいと証明できる」ものになり得ることを示しています。 2016 年、Amazon の小さな研究チームが Automated Reasoning Group (ARG) の発足とともに、その存在を世界に向けて発信しました。掲げたビジョンは大胆なものでした。数学的論理を用いて AWS のシステムをテストするだけでなく、正しく動作することを数学的な確実性をもって証明する、というものです。 それから 10 年。ARG は、形式的検証の進歩によってこれまで解決困難だった問題を AWS の規模で緩和できるのかを模索する段階から、AWS のセキュリティと信頼性への取り組みの根幹を成すシステムを構築する段階へと進みました。ARG の本番サービスは、1 日あたり数十億件のクエリを処理しています。 本記事では、最先端の形式的検証とプログラム解析の技術を Amazon 特有の課題にどう適用してきたかを振り返ります。この取り組みの原動力となったのは、現実世界のセキュリティとインフラストラクチャの問題を、AWS の規模で数学的な厳密さをもって解決できるという確信でした。実際、当時研究していたようなツールは、Intel や NASA では既に成果を上げていました。ただ、これらの技術がここまで広範に適用できるようになるとは、十分に予測できていませんでした。 デモから大規模な本番環境へ 2016 年に第 1 回 ARG Demo Day を開催したとき、AWS Security に向けていくつもの野心的なプロジェクトを紹介しました。それぞれが、同じ根本的な問い、すなわち「自分たちのシステムが安全かつ正しいことを数学によってどう証明できるのか」に対する異なるアプローチでした。その日に示された答えは、2026 年の今も AWS とお客様にとって重要な役割を果たし続けるシステムの土台となっています。 Sean McLaughlin は「Automatic tools for reasoning about virtual private clouds (VPC)」と題したプレゼンテーションを行いました。VPC ネットワークの拡大に伴い、設定ミスやセキュリティ脆弱性を特定できる自動推論ソリューションへの需要が高まっていると指摘したうえで、その答えとして示したのが「 Tiros というツール で、簡単に言えば、ネットワークに関する質問に答えてくれるもの」でした。 Tiros は、 Amazon Inspector のネットワークセキュリティ分析機能の基盤となりました。Amazon Inspector は、クラウドでアプリケーションを構築する数百万のお客様にご利用いただいています。Tiros は AWS 内部でも、多くの AWS サービスにおけるコンプライアンス認証の確認やセキュリティ不変条件の遵守チェックを自動化する用途で使われています。現在では、Amazon Inspector と Reachability Analyzer の両方を支えています。この取り組みからは Zelkova も派生しました。Zelkova は 自動推論 を用いて、ポリシーとそれが将来もたらす結果を分析します。 S3 Block Public Access や IAM Access Analyzer をはじめ、数多くのツールが Zelkova を基盤としています。 同様に、その日には、重要なインフラストラクチャを対象とする詳細な自動解析の活用をテーマにしたプレゼンテーションも行われました。これが、TLS ハンドシェイクの正しさや、暗号、ストレージ、仮想化のコードが備えるその他の性質を証明する取り組みへとつながりました。 紹介した小規模なプロジェクトの中にも、その規模をはるかに超える影響をもたらしたものがあります。価値の高いインフラストラクチャに対する演繹的検証の取り組みを発表した当時、その適用範囲は主に暗号プロトコルの最も深い部分に限られていました。しかし今日、その重要性は飛躍的に高まっています。これを後押ししたのが、証明支援システム (proof assistant) の台頭です。証明支援システムとは、ユーザーが形式的な証明を作成するのを助ける自動化ツールで、自動推論 (AR) チームの senior principal scientist である Leo de Moura が作成した Lean などがあります。AWS は現在、こうしたツールを言語モデルと組み合わせることで、より多くの、そしてはるかに大規模なシステムの証明を見つけられるようになりました。実際、 Nitro Isolation Engine について発表した証明 は、まさにそれを裏付けるものです。これは、AWS のポリシーインタープリターの証明や、暗号基盤の正しさを証明する近年の取り組みの基礎にもなっています。 お客様が信頼を寄せる数学的保証 この 10 年間で、ARG の研究プロトタイプは、数百万の AWS のお客様が毎日利用するサービスへと発展しました。 IAM Access Analyzer は Zelkova を利用して、USAA や GoTo といったお客様がリソースへの意図しないアクセスを特定できるよう支援します。セキュリティポリシーが正しく設定されていることをただ期待するのではなく、お客様はポリシーが実際に何を許可しているのかを、数学的な証明という形で確認できます。 2016 年にデモを行った Tiros をベースに構築された Reachability Analyzer は、パケットを 1 つも送信することなく、ネットワークの接続性を把握できるよう支援します。設定をテストするのではなく、考えられるすべてのネットワーク経路を数学的に分析し、宛先に到達できるかどうか、到達できない場合はどのコンポーネントが妨げているのかを示します。 Amazon Bedrock Guardrails の 自動推論チェック は、生成 AI に数学的な検証をもたらします。この機能は、モデルの応答が定義されたポリシーに準拠していることを形式論理で検証し、AI のハルシネーションの防止に役立ちます。検証精度は最大 99% に達します。 これらのお客様向けサービスには共通の基盤があります。いずれも 充足可能性モジュロ理論 (satisfiability modulo theories、SMT) ソルバーなどの自動推論技術を用いてシステムの動作に関する数学的保証を提供し、従来のテストで到達できる範囲をはるかに超えています。 クラウドを支えるインフラストラクチャの正しさの証明 お客様向けのツールは自動推論の実用的な価値を示すものですが、最も困難な取り組みの一部は AWS 内部のインフラストラクチャに向けられてきました。数百万のワークロードが依存しているため、正しさが不可欠なシステムです。 AWS は自動推論を用いて、次に挙げるものをはじめ、インフラストラクチャの多くの部分について正しさを証明してきました。 AWS Nitro Isolation Engine s2n-bignum などの暗号実装 AWS データセンターで動作するブートコード S3 などのストレージシステム とりわけ野心的だったプロジェクトでは、1 秒あたり 10 億回の API コールを処理する認可エンジン全体の正しさを証明し、シームレスに置き換えました。仕様と証明を用い、新しいエンジンを数千兆件に及ぶ本番環境の認可判定に対して検証したのです。 こうした内部検証の取り組みは、クラウドインフラストラクチャの最も基礎的な層に対しても、自動推論が数学的確実性をもたらせることを示しています。 予想外の発見 この 10 年の取り組みでおそらく最も意外だったのは、自動推論はシステムをより安全にするだけでなく、多くの場合、より効率的で保守しやすいものにするという発見です。検証のために厳密な仕様を書く必要が生じると、チームはより単純で洗練された解決策に気付くことがよくあります。 その理由の一つは、自動推論によって可能になる、システム全体を対象としたアプローチにあります。自動推論は、特定のシナリオにおけるシステムの動作を検証することに主眼を置くのではなく、論理を用いて 起こり得るあらゆる シナリオでの動作を検証します。考えられるすべての入力シナリオとその失敗のしかたを洗い出すのではなく、システムがどのように動作すべきかを定義し、その動作に必要な条件を特定します。そして、それらの条件が真であることを数学的証明によって検証します。つまり、システムそれ自体が正しいことを検証できるのです。 この発見は、数学的な厳密さと実践的なエンジニアリングは対立するものではなく、互いに補い合うものだという確信を裏付けました。形式的検証に求められる規律は、そうでなければ見えないままだった単純化の機会をしばしば浮かび上がらせます。 エージェンティック AI を支える基盤の構築 10 年前に始めた研究によって、AWS は AI 開発の次の時代に向けた独自の強みを備えることになりました。分散システムや重要なコードの検証で培った成果は、いまや AI が生成したコードの検証に直接活かせる土台となっています。一方、AWS ポリシーや VPC ネットワークの設定ミスに関する研究は、AI が生成したコンテンツの正しさを検証するのに役立っています。 この進化は、近年のいくつかのローンチに表れています。 Amazon Bedrock Guardrails の自動推論チェック は、深い専門知識を必要とするツールから、ビルダーが毎日使うサービスに直接組み込まれた機能へと歩を進めた、重要な節目です。 Amazon Bedrock AgentCore の Policy は、自動推論を用いてエージェントのアクションに明確な境界を設定し、エージェントが自律的に動作しながらも定められたコンプライアンスの境界内にとどまるようにします。チームは自然言語で、エージェントがアクセスできるツールとデータを指定できます。 AgentCore Gateway と統合すれば、システムはミリ秒単位でポリシーをチェックします。 エージェンティックな開発環境である Kiro では、 要件分析機能 をリリースしました。この機能は自動推論を用いて、コードを書く前にソフトウェア要件に矛盾、あいまいさ、抜け漏れがないことを証明し、コードの正確性を高め、後々のデバッグの繰り返しを防ぎます。Kiro を開発しているチーム自身も、機能を公開する前に、その機能を実装する AI 生成コードが正しく動作するかを自動推論で確認しています。 AI エージェントがより自律的になり、より複雑なタスクを担うようになるほど、その動作に関する数学的保証は決定的に重要になります。AI エージェントが形式仕様を備えたシステムへのコード変更を提案すれば、そのシステムは数学的証明に照らして変更を自動的に検証できます。自動推論は、強力であるだけでなく、安全性と信頼性を証明できる AI システムを構築する道筋をもたらします。 10 年にわたるコラボレーション この取り組みは、築き上げてきた優秀なチームと、重要なインフラストラクチャの保護を AWS に託してくださったお客様なしには実現できませんでした。AWS 全体で、各チームが自動推論の能力を拡大し続けています。 Senior principal scientist の Daniel Kroening が率いる Annapurna のチームは、ハードウェア検証を前進させています。Senior applied scientist の Nadia Labai は、自然言語を形式的な数学的証明へ変換することを AI システムに学習させる自動形式化 (auto-formalization) の研究を切り開いています。Principal applied scientist の Tristan Ravitch が率いる AWS Security のチームは、AWS と Amazon の全アカウントにわたるデータフローを自動的に追跡する Peri をローンチしました。サービスチーム側でのオンボーディングは一切不要です。 これらの取り組みによって、AWS は自動推論の次の 10 年を、最初の 10 年と同じくらい、あるいはそれ以上に変革的なものにする態勢を整えています。 証明してきたこと 10 年を経て、これまで達成してきたことに大きな喜びを感じています。設定エラーの防止から AI システムの動作に関する数学的保証の提供まで、自動推論はあらゆる層で測定可能な価値をもたらすことを証明してきました。そして、数学的な厳密さと実践的なエンジニアリングが手を携えて、お客様が実際に抱える課題を大規模に解決できることを示してきました。 2016 年の最初の Demo Day から今日に至るまでの道のりは、学術的な進歩をお客様が日々頼りにするサービスへと変えていくという AWS の姿勢を体現しています。数学的確実性を通じて信頼の基盤を築いてきました。その基盤は、AI イノベーションの次の 10 年を進むうえで欠かせないものとなるでしょう。 次の 10 年に向けて。 著者について Byron Cook Amazon の vice president 兼 distinguished scientist である Byron Cook は、形式的検証分野のリーダーです。SAT、SMT、記号モデル検査への貢献と、それらを生物システム、コンピュータオペレーティングシステム、プログラミング言語、セキュリティへ応用したことで知られています。Amazon での Byron の自動推論の取り組みは、クラウドにおけるより高い水準の保証と、新しいお客様向け機能をもたらしました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

G-gen の今村です。オンプレミスの PostgreSQL から Cloud SQL for PostgreSQL への移行において、 postgresql.conf の設定をどのように扱うべきか、マネージドサービスの仕様に基づくパラメータの分類と代替手法を解説します。 概要 データベースフラグの概要 データベースフラグとは フラグ設定時の注意点 設定値の確認と更新 パラメータの確認 パラメータの更新 Google が管理するパラメータ 前提と注意点 ネットワークと接続管理 ログ管理 ハードウェア依存の設定 ユーザーが管理するパラメータ 前提と注意点 パフォーマンスチューニングフラグ データベース内での代替設定 概要 Cloud SQL for PostgreSQL をデータベースとして採用する場合や、オンプレミスの PostgreSQL から Cloud SQL for PostgreSQL への移行を検討する際、データベース管理者が直面するのが postgresql.conf で定義するパラメータの扱いです。 Cloud SQL はフルマネージドサービスであるため、OS やインフラストラクチャの運用から解放される半面、すべてのパラメータを自由に設定できるわけではありません。また、設定できる項目とそうでない項目は、Cloud SQL の仕様によってあらかじめ決まっています。 当記事では、オンプレミス版（オープンソース版）の PostgreSQL でよく使用されるパラメータを例に挙げて、それらが Cloud SQL 版では Google が管理するパラメータ （サービスが管理するためユーザー側で設定が不可のパラメータ）と ユーザーが管理するパラメータ のどちらに分類されるかを解説します。あわせて、設定がサポートされていないパラメータの代替手法についても紹介します。 Cloud SQL の基本的な知識については、以下の記事を参照してください。 blog.g-gen.co.jp データベースフラグの概要 データベースフラグとは オンプレミス環境では、PostgreSQL のシステム全体の設定は主に postgresql.conf ファイルで管理します。しかし、Cloud SQL ではマネージドサービスの性質上、このファイルを直接編集できません。 代わりに、Cloud SQL では データベースフラグ を使用してパラメータを設定します。データベースフラグは MySQL や SQL Server でも同様にサポートされていますが、当記事では PostgreSQL を例に解説します。 参考 : データベース フラグを構成する フラグ設定時の注意点 データベースフラグを構成する際、以下の2点に注意する必要があります。 1つ目は、サポートされる値や範囲の違いです。各フラグについて、Cloud SQL でサポートされる値や範囲が、対応する PostgreSQL のパラメータやオプションと異なる場合があります。 2つ目は、再起動の発生です。すでに起動しているデータベースインスタンスに対してフラグを設定、変更、または削除すると、インスタンスの再起動が必要になる場合があります。稼働中のシステムに変更を加える際は、ダウンタイムに留意してください。 参考 : データベース フラグを構成する - サポートされているフラグ 設定値の確認と更新 パラメータの確認 Google Cloud コンソールから、現在インスタンスに設定されているデータベースフラグの一覧を確認できます。該当インスタンスの概要ページを開き、データベースフラグのセクションを確認します。 参考 : データベース フラグを構成する - インスタンスに設定されているデータベース フラグを確認する 設定されているデータベースフラグの例 また現在の設定値は、 psql クライアントなどでインスタンスにログインし、以下の SQL 文を実行することでも確認可能です。 SELECT name, setting FROM pg_settings; 参考 : データベース フラグを構成する - データベース フラグの現在の値を表示する パラメータの更新 Google Cloud コンソールや gcloud コマンドを使用して変更を行います。 システム全体に影響を与えるパラメータの多くは、このデータベースフラグを通じて設定が可能です。 Cloud SQL インスタンスを編集 フラグとパラメータの編集 gcloud コマンドでは、以下のようにフラグ名と値を対応させて実行します。 gcloud sql instances patch INSTANCE_NAME \ --database-flags = FLAG1 =VALUE1, FLAG2 =VALUE2 参考 : データベース フラグを構成する - データベース フラグを設定する Google が管理するパラメータ 前提と注意点 当セクションで紹介する「Google が管理するパラメータ」は、Cloud SQL では Google が完全に管理しており、ユーザー側で設定できないものです。これらはデータベースフラグとしてサポートされていません。 なお、当セクションで紹介するパラメータは、よく用いられる設定のごく一部です。実際には、システム要件と公式ドキュメントを照らし合わせ、事前に十分なパラメータ設計を行ってください。 ネットワークと接続管理 オンプレミスでは必須となる listen_addresses や port の設定は、Google Cloud では不要です。 Cloud SQL では、PostgreSQL の標準ポート（ 5432 ）が固定で使用されます。アクセス制御は pg_hba.conf を編集するのではなく、VPC ネットワークピアリングや承認済みネットワークなど、Google Cloud のネットワーク機能を使用して管理します。 参考 : Cloud SQL への接続方法を選択する 参考 : 接続の問題をデバッグする - 開いているローカルポート インスタンスの接続情報 VPC についての詳細は、以下の記事を参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp ログ管理 log_destination 、 logging_collector 、 log_file_mode などのログファイルの出力先やローテーションに関する設定もマネージドサービスで代替可能です。 Cloud SQL のログは自動的に Cloud Logging に統合されます。ログの検索、監視などはデータベース側で行うのではなく、Google Cloud のオブザーバビリティ機能を使用して行います。 参考 : インスタンスのログを表示する Cloud Logging についての詳細は、以下の記事を参照してください。 blog.g-gen.co.jp ハードウェア依存の設定 dynamic_shared_memory_type などの OS やハードウェア基盤に強く依存するパラメータは設定できません。これらは Cloud SQL の基盤側で自動的に最適化されるため、ユーザーが意識する必要はありません。 参考 : マシンシリーズを選択する ユーザーが管理するパラメータ 前提と注意点 当セクションで紹介する「ユーザーが管理するパラメータ」は、Cloud SQL に移行した後でも、引き続きユーザー側でチューニングや設定を行う必要があるパラメータです。 当セクションで紹介するパラメータは例示であり、ごく一部です。実際には、システム要件を考慮し、どのパラメータに対してフラグや代替手段を用いた設定が必要になるのかを、公式ドキュメントと照らし合わせて十分に精査してください。 パフォーマンスチューニングフラグ max_connections 、 shared_buffers 、 maintenance_work_mem など、データベースのパフォーマンスに直結する重要なパラメータの多くが、データベースフラグとしてサポートされています。 なお、一部のフラグ（ max_connections や max_worker_processes など）は、インスタンスのメモリサイズに応じて上限値やデフォルト値が自動的にスケーリングする仕様になっています。オンプレミスの設定値をそのまま移行するのではなく、自動設定されるデフォルト値を確認し、マネージドサービスへ設定を委譲できるかを評価してください。 参考 : データベース フラグを構成する - サポートされているフラグ データベース内での代替設定 データベースフラグのリストに存在しない場合でも、 ALTER DATABASE などの SQL コマンドを用いてデータベース内で設定できるパラメータがあります。 例えば、タイムゾーン（ timezone ）、日付の表示形式（ datestyle ）、ロケール書式（ lc_monetary や lc_numeric など）は、インスタンス全体のフラグとして設定できなくても、特定のデータベースやユーザーに対して個別に適用できます。 マルチテナント環境などで、データベースごとに異なる言語設定や検索設定（ default_text_search_config ）を適用したい場合に有効な手法です。 参考 : データベース フラグを構成する - トラブルシューティング ALTER DATABASE の実行例 今村 壱生 (記事一覧) クラウドソリューション部 ソリューションアーキテクト課 2026年3月にG-genへ入社。約7年間 Web 広告運用やウェブ解析に携わり、その後は社内 SE として開発業務に従事。広告運用の現場感と技術的な視点、その双方を併せ持つ経験をベースに、現在は Google Cloud のスキルアップに注力。データ活用とクラウド技術を融合させ、お客様のビジネス成長を支えるエンジニアを目指している。 Follow