Azure Database for PostgreSQL の2026年4月更新では、既存サーバーの次回メンテナンス時に反映される変更として、PostgreSQLマイナーバージョン更新、Premium SSD V2の一般提供、Cascading Replicasの一般提供、Fabric mirroringの対応拡大、pgvectorやpg_duckdbなど拡張機能の更新が含まれています。特に data engineers、DBAs、analytics leaders は、レプリカ構成、ネットワーク移行、ストレージ、分析連携、拡張機能の互換性を事前に確認しておくべきです。
今回の更新は単なる定期メンテナンスではありません。新規サーバーは2026年4月22日以降に最新バージョンへ自動オンボードされ、既存サーバーは次回のスケジュール済みメンテナンスでアップグレードされます。Microsoft公式のRelease Notes for Azure Database for PostgreSQL Maintenance – April 2026は2026年4月23日に更新されています。(Microsoft Learn)
Azure Database for PostgreSQL の2026年4月更新で押さえるべき結論
今回の Azure Database for PostgreSQL 2026年4月更新で、まず確認すべきポイントは次の4つです。
| 確認ポイント | 影響を受けやすい担当者 | 実務上の確認内容 |
|---|---|---|
| PostgreSQLマイナーバージョン更新 | DBA、SRE | 拡張機能、クエリ、アプリ接続の互換性確認 |
| Premium SSD V2の一般提供 | DBA、インフラ担当、analytics leaders | ストレージ性能、復元、読み取りレプリカ設計の見直し |
| Cascading Replicasの一般提供 | DBA、data engineers | レプリカ構成、DR、分析用読み取り負荷分散の再設計 |
| Fabric mirroring対応拡大 | data engineers、analytics leaders | Microsoft Fabric連携、HA構成、フェイルオーバー時の運用確認 |
今回の更新は、セキュリティパッチや不具合修正だけでなく、分析基盤やレプリケーション設計に関わる機能改善が多く含まれています。特に本番環境で読み取りレプリカ、HA、Private Endpoint、Microsoft Entra ID認証、Microsoft Fabric連携を使っている場合は、メンテナンス前に影響範囲を確認しておく必要があります。
PostgreSQLマイナーバージョン更新：18.3、17.9、16.13、15.17、14.22へ
2026年4月のメンテナンスリリースでは、Azure Database for PostgreSQLの最新マイナーバージョンとして、PostgreSQL 18.3、17.9、16.13、15.17、14.22が反映されます。(Microsoft Learn)
マイナーバージョン更新は、通常メジャーバージョンアップほど大きなアプリケーション変更を伴いません。ただし、データベース運用では「マイナーだから安全」と決めつけないことが重要です。
確認すべき項目は次のとおりです。
| 確認対象 | なぜ重要か | 具体的な確認方法 |
|---|---|---|
| 拡張機能 | バージョン差で挙動や対応範囲が変わる可能性がある | SELECT * FROM pg_extension; で利用中の拡張機能を棚卸しする |
| アプリケーション接続 | ドライバーや接続プールとの相性を確認する必要がある | ステージング環境で接続、トランザクション、タイムアウトを検証する |
| バッチ処理 | 夜間ETLや集計処理は影響が見落とされやすい | 定期ジョブの実行時間とエラー率を比較する |
| クエリ性能 | 統計情報や実行計画の変化が起きる場合がある | 重要クエリの実行計画とレスポンス時間を確認する |
DBAは、メンテナンス後に「接続できるか」だけでなく、業務上重要なSQLが期待どおりの速度で動くかまで確認するべきです。特に、BIダッシュボード、日次集計、外部連携APIのように利用者が多い処理は、事前に代表クエリをリスト化しておくと確認漏れを防げます。
新機能の注目点：PostgreSQL 18でApache AGEとpg_diskANNをサポート
今回のリリースでは、PostgreSQL 18に対してApache AGE拡張機能とpg_diskANN拡張機能のサポートが追加されています。(Microsoft Learn)
Apache AGEは、PostgreSQL上でグラフデータの扱いを可能にする拡張機能として知られています。関係性データを扱うユースケース、たとえば不正検知、推薦、ネットワーク分析、顧客関係分析などで活用余地があります。
pg_diskANNは、ベクトル検索や近似最近傍探索の文脈で注目される拡張機能です。AI検索、RAG、レコメンド、類似文書検索など、生成AIや分析基盤とPostgreSQLを組み合わせる場面で検討対象になります。
ただし、これらの拡張機能は「使えるようになったからすぐ本番導入する」よりも、まずは次の観点で検証するのが現実的です。
| 検証観点 | 確認すべきこと |
|---|---|
| ワークロード適性 | 既存のRDB処理で十分か、グラフ・ベクトル検索が本当に必要か |
| 性能 | データ量増加時の検索時間、インデックスサイズ、CPU・I/O使用率 |
| 運用 | バックアップ、復元、レプリカ、監視で想定外の問題がないか |
| コスト | 専用検索サービスを使う場合と比べて、運用負荷と費用が妥当か |
data engineersにとっては、PostgreSQLを単なるトランザクションDBではなく、分析やAI検索の周辺基盤として使いやすくなる更新です。一方で、DBAは拡張機能の導入によってバックアップ時間、ストレージ使用量、インデックス保守が増えないかを確認する必要があります。
Premium SSD V2が一般提供：ストレージ設計を見直すタイミング
今回の更新で、Premium SSD V2 storageが一般提供になりました。公式リリースでは、読み取りレプリカのインスタントスナップショットアクセス、ポイントインタイムリストア、削除済みサーバーの復元、Customer Managed Keys、オンラインストレージスケーリングが含まれるとされています。(Microsoft Learn)
これはDBAやインフラ担当者にとって大きなポイントです。ストレージは、データベース性能だけでなく、復旧時間、バックアップ戦略、可用性設計に直結します。
Premium SSD V2を検討しやすいケースは次のとおりです。
| ユースケース | 検討理由 |
|---|---|
| 読み取りレプリカを分析用途に使っている | スナップショットやレプリカ周りの運用改善が期待できる |
| PITRを重視する本番環境 | 障害時・誤操作時の復元計画を強化しやすい |
| データ量の増加が読みにくいサービス | オンラインストレージスケーリングにより拡張計画を立てやすい |
| CMKを使う規制対応環境 | 暗号鍵管理の要件に合わせやすい |
注意点は、ストレージを変えれば必ず性能問題が解決するわけではないことです。遅いクエリの原因がインデックス不足、不要なフルスキャン、接続数過多、アプリケーション側のN+1クエリにある場合、ストレージだけを改善しても効果は限定的です。
Premium SSD V2を採用する前に、Azure Monitor、Query Store、実行計画、待機イベントなどを確認し、「I/Oが本当にボトルネックか」を判断してください。
Cascading Replicasが一般提供：分析・DR構成の選択肢が広がる
Cascading Replicasも今回のリリースで一般提供となり、複数の既知の問題が修正されたとされています。(Microsoft Learn)
Cascading Replicasは、プライマリから直接すべてのレプリカをぶら下げるのではなく、レプリカからさらにレプリカを作るような構成を可能にします。これにより、分析用途、地域分散、災害対策、読み取り負荷分散の設計に柔軟性が出ます。
たとえば次のような構成が考えられます。
| 構成例 | 活用シーン |
|---|---|
| プライマリ → レプリカ → 分析用レプリカ | 本番DBへの直接負荷を避けてBIやETLを実行する |
| プライマリ → 地理的レプリカ → ローカル分析レプリカ | 地域ごとの分析やレポート処理を近い場所で実行する |
| プライマリ → DR用レプリカ → 検証用レプリカ | 災害対策環境を保ちながら検証環境を分離する |
analytics leadersにとっては、分析基盤の応答速度や可用性を高める選択肢になります。DBAにとっては、レプリケーション遅延、フェイルオーバー時の整合性、監視ポイントの増加に注意が必要です。
導入時は、単にレプリカを増やすのではなく、次のように目的を明確に分けると失敗しにくくなります。
| レプリカの目的 | 設計上の注意点 |
|---|---|
| BI・ダッシュボード | ピーク時の読み取り負荷と更新遅延を確認する |
| ETL・ELT | 大量抽出がレプリカ遅延を悪化させないか確認する |
| DR | RPO、RTO、フェイルオーバー手順を文書化する |
| 開発・検証 | 本番データの取り扱いとアクセス権限を制御する |
VNETからPrivate Endpointへの移行がHA有効サーバーでも利用可能に
今回のリリースでは、HAが有効なサーバーに対して、Virtual NetworkからPrivate Endpointへの移行が利用可能になりました。(Microsoft Learn)
これはネットワーク設計を見直している組織にとって重要です。Private Endpointを使うことで、Azure内のプライベート接続を中心とした構成に寄せやすくなります。特に、インターネット公開を避けたい本番データベースや、ゼロトラストを意識したネットワーク設計では検討価値があります。
ただし、ネットワーク移行はデータベース本体の変更以上に、周辺サービスへの影響が出やすい領域です。次の接続元を必ず洗い出してください。
| 接続元 | 確認内容 |
|---|---|
| アプリケーションサーバー | 接続文字列、DNS解決、ファイアウォール設定 |
| BIツール | Private Endpoint経由で接続できるか |
| ETL基盤 | Self-hosted Integration Runtimeや実行環境のネットワーク経路 |
| 運用端末 | 踏み台、VPN、管理者アクセスの経路 |
| 監視ツール | メトリック収集やヘルスチェックの接続可否 |
今回の修正では、VNETからPrivate Endpointへの移行時にpublic accessが有効のまま残る可能性がある問題も修正されています。(Microsoft Learn) メンテナンス後は、ポータルやAzure CLIでpublic accessの状態を確認し、意図しない公開経路が残っていないかをチェックすることが重要です。
Fabric mirroringの対応拡大：読み取りレプリカとHA構成での利用に注目
Microsoft Fabricを使っている組織にとって、今回のFabric mirroring関連の更新は見逃せません。2026年4月更新では、読み取りレプリカを持つサーバーでFabric mirroringが有効になり、さらにPostgreSQL 14〜16で稼働するHA PostgreSQLサーバーでも利用可能になりました。(Microsoft Learn)
ただし、PostgreSQL 14〜16のHAサーバーでは、フェイルオーバー後にmirroringの再起動が必要とされています。PostgreSQL 17以降とは運用差があるため、HA構成だから安心と考えず、フェイルオーバー時の復旧手順にFabric mirroringの確認を含めるべきです。(Microsoft Learn)
analytics leadersは、Fabric mirroringによって分析データ連携の選択肢が増える一方で、次の点を確認しておくと実務で混乱しにくくなります。
| 確認項目 | 実務上の意味 |
|---|---|
| フェイルオーバー後の再起動手順 | 障害時に分析データ連携が止まったままになるリスクを下げる |
| データ反映遅延 | リアルタイム性が必要な指標に使えるか判断する |
| レプリカ構成との関係 | 本番負荷を抑えながら分析連携できるか確認する |
| 監視体制 | mirroring停止や遅延を検知できるようにする |
BIや経営ダッシュボードでFabric連携を使っている場合、DBAだけでなく、データ基盤チームと業務部門も含めて「どの指標がどの程度遅延しても許容されるか」を事前に合意しておくことが大切です。
Cross-Tenant CMKはPrivate Preview：すぐ本番採用ではなく要件確認から
今回の更新では、Cross-Tenant Customer Managed KeysのサポートがPrivate Previewとして導入されています。(Microsoft Learn)
これは、テナントをまたいだCustomer Managed Keysの利用を検討する企業に関係する機能です。たとえば、複数のAzureテナントを持つグループ会社、M&A後の統合環境、セキュリティ部門が鍵管理を集約している組織などでは関心の高いテーマです。
ただし、Private Previewの機能は、一般提供機能と同じ前提で本番計画に組み込むべきではありません。利用可否、対象リージョン、サポート条件、制限事項は変わる可能性があります。
検討時は、次のように段階を分けると安全です。
| 段階 | やること |
|---|---|
| 要件整理 | 鍵管理を別テナントにする必要性を明確にする |
| セキュリティ確認 | Key Vault、権限、監査ログ、運用責任を確認する |
| 検証 | 非本番環境で暗号化、復元、アクセス権限を検証する |
| 本番判断 | 一般提供状況やサポート条件を確認してから採用する |
pg_duckdbとpgvectorの更新：分析・AI検索の運用に影響
今回の改善では、pg_duckdb拡張機能がバージョン1.1.1へ更新され、Azure Blob Storageへの書き込みサポートと改善が追加されています。また、pgvectorは0.8.0.2へ更新されています。(Microsoft Learn)
data engineersにとって、pg_duckdbの更新はデータレイクやBlob StorageとPostgreSQLをつなぐ分析処理で注目できます。たとえば、PostgreSQL上のデータを外部ストレージへ書き出し、別の分析パイプラインで処理するような構成では、設計の選択肢が増えます。
pgvectorの更新は、生成AIアプリケーション、RAG、類似検索、検索拡張型チャットボットなどに関係します。Azure Database for PostgreSQLをAIアプリケーションのベクトルストアとして使っている場合は、メンテナンス後に検索精度だけでなく、インデックス作成時間、検索レスポンス、ストレージ使用量も確認してください。
特に注意したいのは、AI検索系の処理は「動くかどうか」だけでは品質を判断できない点です。次のような観点で確認すると、実運用に近い評価ができます。
| 評価観点 | 確認例 |
|---|---|
| 検索品質 | 期待する文書が上位に出るか |
| 応答速度 | ユーザーが許容できる秒数で返るか |
| コスト | インデックスサイズやCPU負荷が増えすぎていないか |
| 再現性 | 同じ条件で安定した結果が得られるか |
| 障害時対応 | インデックス再作成や復旧手順が明確か |
ネットワークとDNS関連の改善：見落としやすいが運用負荷に効く
今回の更新では、Private DNS ZoneのサブスクリプションがMicrosoft.DBforPostgreSQLに登録されていない場合のエラーハンドリングが改善され、長いリトライを避け、より分かりやすいエラーを表示するようになりました。(Microsoft Learn)
また、Flexible Server統合でIPv4とIPv6の両方を持つサブネットがサポートされました。ただし、PostgreSQL接続は引き続きIPv4に限定されています。(Microsoft Learn)
この点は、ネットワーク担当者とDBAの認識ずれが起きやすいポイントです。「サブネットがIPv6対応になった」ことと、「PostgreSQL接続がIPv6でできる」ことは同じではありません。接続テストや設計書では、PostgreSQLクライアント接続がIPv4であることを明記しておくと、トラブルを避けやすくなります。
データ型変換とエクスポート改善：ETL・分析パイプラインで確認すべき点
今回の更新では、制約のないnumeric列のエクスポート動作が改善され、既定でDecimal128(38, 0)を使用するようになりました。これにより、SQL標準の慣例に合わせ、不要な小数桁を避ける意図があります。(Microsoft Learn)
また、XML、JSON、JSONB、INET、CIDR、MACADDR、TSVECTOR、範囲型、幾何型など、複数のPostgreSQLネイティブ型が文字列表現に変換される変更も含まれています。(Microsoft Learn)
この変更は、data engineersにとって重要です。エクスポート先や分析基盤側で、型の扱いが変わると、ETL処理やスキーママッピングで想定外のエラーが起きる可能性があります。
確認すべき代表例は次のとおりです。
| 対象 | 起こりやすい問題 | 対策 |
|---|---|---|
| numeric列 | 小数桁や精度の解釈が変わる | エクスポート後のスキーマを確認する |
| JSON/JSONB | 文字列として扱われ、後段処理でパースが必要になる | 取り込み側でJSONパース処理を明示する |
| INET/CIDR | IPアドレス型として処理していたロジックが崩れる | 文字列からの変換処理を追加する |
| 範囲型・幾何型 | BIツールで自動認識されない | 表示用・分析用の変換列を用意する |
本番パイプラインでは、更新後すぐに全データを流すのではなく、代表データでスキーマ、型、NULL、桁数、文字列表現を確認してから本処理へ進むのが安全です。
不具合修正：Entra ID認証、Private Endpoint、セキュリティパッチに注目
2026年4月更新では、既知の問題修正も複数含まれています。特に重要なのは、Microsoft Entra ID認証、Private Endpoint構成、セキュリティ修正です。
Microsoft Entra ID認証とPgBouncerを組み合わせている場合、Entra IDトークンサイズが4KBを超えると認証失敗につながる可能性がある問題が修正されています。(Microsoft Learn)
また、Private Endpointが構成されたサーバー削除時の競合状態の処理改善、VNETからPrivate Endpointへの移行時にpublic accessが有効のまま残る可能性がある問題の修正も含まれています。(Microsoft Learn)
さらに、PostgreSQL 11〜13のextended supportにおいて、CVE-2026-2004、CVE-2026-2005、CVE-2026-2006、CVE-2025-4207に対するセキュリティ修正が含まれています。(Microsoft Learn)
DBAがメンテナンス後に優先して確認すべき項目は次のとおりです。
| 優先度 | 確認項目 | 理由 |
|---|---|---|
| 高 | Entra ID認証とPgBouncerの接続確認 | アプリケーション接続障害に直結する可能性がある |
| 高 | public accessの状態確認 | 意図しない公開経路を防ぐため |
| 高 | Private Endpoint経由の接続確認 | ネットワーク移行後の影響を把握するため |
| 中 | サーバー削除・復元手順の確認 | 運用手順と実際の挙動に差がないか確認するため |
| 中 | extended support対象バージョンの棚卸し | 古いPostgreSQLバージョンのリスク管理が必要なため |
役割別に見る、今回の更新でやるべきこと
今回の Azure Database for PostgreSQL 2026年4月更新は、担当者ごとに見るべきポイントが異なります。全員が同じリリースノートを読むより、役割別にチェックリストを分けると効率的です。
data engineersが確認すべきこと
data engineersは、データ連携と分析パイプラインへの影響を重点的に確認してください。
| 確認項目 | 実務アクション |
|---|---|
| pg_duckdb更新 | Blob Storage連携や書き出し処理を非本番で検証する |
| pgvector更新 | RAGや類似検索のレスポンス、検索品質、インデックスを確認する |
| Fabric mirroring | レプリカあり構成、HA構成での反映遅延と停止時の復旧手順を確認する |
| データ型変換 | JSON、numeric、範囲型、ネットワーク型の後段処理を確認する |
| Cascading Replicas | ETLやBIの読み取り先を本番プライマリから分離できるか検討する |
特に、分析基盤では「データは届いているが型が変わって集計結果がずれる」という問題が起きやすいです。更新後は、件数一致だけでなく、代表的な集計値やNULL件数、型変換後の値も比較してください。
DBAsが確認すべきこと
DBAは、可用性、接続、セキュリティ、復旧の観点で確認する必要があります。
| 確認項目 | 実務アクション |
|---|---|
| マイナーバージョン更新 | 重要クエリ、拡張機能、接続プールを検証する |
| Premium SSD V2 | PITR、削除済みサーバー復元、オンラインスケーリングの運用手順を確認する |
| Private Endpoint | DNS、public access、接続元、ファイアウォールを確認する |
| Entra ID認証 | PgBouncer利用環境で認証テストを行う |
| セキュリティ修正 | extended support対象のPostgreSQL 11〜13を棚卸しする |
本番DBで最も避けたいのは、メンテナンス後に「アプリは動いているが一部の管理機能や分析連携だけ失敗している」状態です。メンテナンス後の確認手順には、アプリ接続、管理者接続、レプリカ、バックアップ、復元、監視、外部連携を含めてください。
analytics leadersが確認すべきこと
analytics leadersは、今回の更新を単なるDB保守ではなく、分析基盤の改善機会として見るべきです。
| 確認項目 | 判断ポイント |
|---|---|
| Fabric mirroring | Microsoft Fabricを使った分析連携をどこまで標準化するか |
| Cascading Replicas | 本番負荷を抑えながら分析チームへデータ提供できるか |
| Premium SSD V2 | レポート遅延や復旧時間の改善に寄与するか |
| pgvector | AI検索やナレッジ検索の基盤としてPostgreSQLを使うか |
| Cross-Tenant CMK | グループ会社や複数テナント環境の鍵管理方針に合うか |
分析リーダーが注意すべきなのは、機能追加によって選択肢が増えるほど、アーキテクチャが複雑になりやすい点です。すべての機能を採用するのではなく、「何を速くしたいのか」「何を安全にしたいのか」「どの運用負荷を減らしたいのか」を決めてから導入判断を行うべきです。
メンテナンス前後の実務チェックリスト
Azure Database for PostgreSQLのメンテナンスでは、事前確認と事後確認を分けるとトラブル対応がしやすくなります。
メンテナンス前にやること
| チェック項目 | 具体的な作業 |
|---|---|
| 対象サーバー確認 | 本番、ステージング、分析用、レプリカを一覧化する |
| 利用機能の棚卸し | HA、Private Endpoint、PgBouncer、Entra ID、Fabric mirroring、拡張機能を確認する |
| 重要SQLのリスト化 | 業務影響の大きいクエリ、バッチ、APIを選定する |
| 接続元確認 | アプリ、BI、ETL、監視、運用端末を洗い出す |
| 復旧手順確認 | PITR、バックアップ、フェイルオーバー、レプリカ再作成の手順を確認する |
メンテナンス後にやること
| チェック項目 | 具体的な作業 |
|---|---|
| バージョン確認 | PostgreSQLのマイナーバージョンと拡張機能バージョンを確認する |
| 接続確認 | アプリ、PgBouncer、Entra ID認証、管理者接続を確認する |
| ネットワーク確認 | Private Endpoint、DNS、public access、Firewall設定を確認する |
| レプリカ確認 | Cascading Replicas、geo-replica、読み取りレプリカの遅延を確認する |
| 分析連携確認 | Fabric mirroring、ETL、BI、Blob Storage連携を確認する |
| 性能確認 | 重要クエリの実行時間、CPU、I/O、接続数、待機イベントを確認する |
特におすすめなのは、メンテナンス後の確認結果を「接続」「性能」「セキュリティ」「分析連携」の4分類で記録することです。障害が発生した場合でも、どこまで正常確認済みかが分かり、切り分けが速くなります。
失敗しやすいポイントと回避策
今回の更新で起きやすい失敗は、機能単位ではなく運用のつながりで見落とすことです。
| 失敗しやすいポイント | なぜ起きるか | 回避策 |
|---|---|---|
| マイナーバージョン更新を軽視する | 影響が小さいと思い込み、検証を省く | 重要SQLと拡張機能だけでも事前確認する |
| Fabric mirroringの再起動を忘れる | HAフェイルオーバー時の手順に含まれていない | 障害対応Runbookにmirroring確認を追加する |
| public accessの状態を見落とす | Private Endpoint移行後に接続確認だけで終える | セキュリティ設定をメンテナンス後チェックに含める |
| レプリカを増やしすぎる | 分析要件ごとに個別レプリカを作ってしまう | 用途、RPO/RTO、遅延許容度を整理して設計する |
| データ型変換を後段で吸収できない | ETLやBI側のスキーマ前提が固定されている | 代表データで型、桁数、NULL、文字列表現を確認する |
運用で重要なのは、リリースノートを読むだけでなく、自社環境の利用機能に置き換えることです。たとえば「pgvectorが更新された」という情報は、AI検索を使っていない環境では優先度が低いかもしれません。一方、RAGアプリケーションの中核に使っている環境では、最優先の検証対象になります。
今回の更新をどう活用すべきか
Azure Database for PostgreSQL の2026年4月更新は、セキュリティと安定性を高めるだけでなく、分析・AI・レプリケーション・ストレージ設計を見直すきっかけになります。
まずDBAは、マイナーバージョン、拡張機能、接続、Private Endpoint、セキュリティ設定を確認してください。data engineersは、pg_duckdb、pgvector、Fabric mirroring、データ型変換、ETL処理への影響を検証するべきです。analytics leadersは、Premium SSD V2、Cascading Replicas、Fabric mirroringを使って、分析基盤の可用性と拡張性を高められるかを判断してください。
次に取るべき行動は、公式リリースノートの内容を自社環境に照らし合わせ、次の3つに分類することです。
| 分類 | 例 | 対応 |
|---|---|---|
| すぐ確認する項目 | Entra ID認証、Private Endpoint、public access、重要SQL | メンテナンス前後のチェックリストに入れる |
| 検証してから使う項目 | pgvector、pg_duckdb、Fabric mirroring、Cascading Replicas | 非本番環境で性能・運用を確認する |
| 中長期で検討する項目 | Premium SSD V2、Cross-Tenant CMK、分析アーキテクチャ見直し | コスト、セキュリティ、運用体制を含めて判断する |
今回の更新を安全に取り込むには、まず利用中のAzure Database for PostgreSQLサーバーを一覧化し、HA、レプリカ、Private Endpoint、PgBouncer、Entra ID認証、Fabric mirroring、拡張機能の利用有無を確認してください。そのうえで、影響がある項目から順にステージング環境で検証し、本番メンテナンス後の確認手順に落とし込むことが、最も現実的で失敗しにくい進め方です。
コメント