# PMI韓国支部の教育委員会でボランティアを始めました：合格体験記のその後 > PMP合格後にPMI韓国支部の教育委員会でボランティアを始めた理由、支部と教育委員会の活動、一緒に勉強したい人の参加方法をまとめた、「PMP合格ロードマップ」シーズン1の最終回です。 _Slug: pmi-korea-chapter-education-committee · 2026-10-02_ PMPの準備をしていた7週間、私はいつも受け取る側でした。韓国のPMPコミュニティの合格体験記やReddit r/PMPの投稿をほぼ毎日読み、顔も知らない人たちが残した記録に支えられて勉強しました。これからは、少しでも恩返しをする側に回ってみようと思います。 **3行まとめ**：PMP合格後、PMI韓国支部（PMI 한국챕터）の教育委員会でボランティアを始めました。教育委員会は、支部の勉強会や研究会を審査して承認し、無料のZoomやメンバー募集を支援し、活動証明書と一部のPDUを発行しています。ひとりで準備しながら受けた助けを、今度は韓国の受験者がみんなで勉強するために役立てたいと思っています。 [第14回](/ja/posts/is-pmp-worth-it-salary-benefits)では、PMPが実務や年収、採用にとってどんな意味を持つのかを検証しました。でも、数字では測りにくいものがもうひとつあります。同じ道を歩む人たちとつながることです。この記事はその話であり、「PMP合格ロードマップ」シーズン1の最終回でもあります。 ## 受け取るばかりだった7週間 私はPMPをひとりで準備しました。オンライン講座を受け、Study Hallの問題を解き、間違いノートを書き、ChatGPTとNotebookLM（現 Gemini Notebook）で復習しました。一緒に勉強する仲間はいませんでしたが、その代わり、いつも誰かの書いた記事がそばにありました。 Full Mock（模擬試験）の点数が66%と65%だったときは、「この点数で受験して大丈夫だろうか？」と不安になり、似たような点数で合格した人の体験記を探して読みました。そこから本当にたくさんの助けをもらいました。だから[合格体験記の第1部](/ja/posts/pmp-pass-review-part-1)を書いたときも、この記事が誰かにとって小さな地図になればうれしいと書きましたし、このシリーズもその気持ちから続いてきました。 でも、文章では届かない場所があります。一緒に問題を解き、点数について話し合い、心が揺らいだときに支えてくれる人。ひとりで勉強していると、その場所は空いたままです。 ## PMI韓国支部はこんなところです PMI韓国支部（[pmikorea.kr](https://pmikorea.kr)）は、PMIのリストに「South Korea Chapter」として載っている支部です。アジア太平洋地域に属し、2012年に支部として認可（charter）を受けました。運営はボランティアが担っています。 支部では、次のような活動をしています。 - 毎月のセミナー（PDU対象） - 隔月開催のオンライン「PMコラムセミナー」（PM 칼럼 세미나）：会員無料、PDU対象 - 勉強会と研究会 - 実務者どうしのネットワーキング - 大学生のプロジェクトコンテスト ## 教育委員会の仕事 支部には6つの委員会があり、教育委員会（교육위원회）はそのひとつです。教育委員会のコミュニティ支援案内（2025年9月1日付）を見ると、役割はかなりはっきりしています。 - 支部の勉強会・研究活動を管理します。 - 勉強会や研究会を立ち上げたい人を審査・面談したうえで承認します。 - 活動中のグループを見守り、必要なら承認を取り消すこともあります。 - 無料のZoomを提供し、メンバー募集を手伝います。 - 活動証明書と一部のPDUを発行します。 ひと言でいえば、支部の中で一緒に勉強する場がきちんと回るように支える存在です。 ## 私がやりたいこと 私はこの教育委員会でボランティアをしています。大きな計画を並べるよりも、やりたいことを1行で書いておきます。**勉強会がうまく回るように手助けすること**です。 ひとりで準備したからこそ、どこで心が揺らぐのかがわかります。点数が伸び悩むとき、同じ理由で何度も間違えるとき、試験日を決めるか迷うときです。そんなとき、同じ試験を準備している人たちがそばにいれば、揺らぐこともずっと少なくなるはずです。韓国の受験者がひとりではなく一緒に勉強できるように、そんな場をつくる手伝いをしたいと思っています。 ## ボランティアで得られるもの 正直に言うと、私にも得るものがあります。 ひとつめはPDUです。支部でのボランティアは、PMPの維持に必要なPDUのうちGiving Backとして認められます。[第11回](/ja/posts/pmp-60-pdu-renewal-plan)で公開した私の3年計画にも、教育委員会でのボランティアで12PDUを入れてあります。 ふたつめは人です。ほかの会社、ほかの業界でプロジェクトを率いている実務者に出会えます。試験勉強のときは文章でしか会えなかった人たちと、これからは直接つながることができます。 ## 一緒に参加したい方へ PMPを準備している方、あるいはすでに取得してPDUを満たす必要がある方は、まず支部から始めてみてください。 - **支部の会員になる**。会費はPMIストアで約$22です。 - **セミナー**。毎月のセミナーも隔月のオンラインPMコラムセミナーもPDU対象で、PMコラムセミナーは会員なら無料です。 - **勉強会**。募集中の勉強会に参加してもいいですし、自分で立ち上げたい場合は、教育委員会の審査を経て、無料のZoomとメンバー募集の支援を受けられます。 セミナーの日程やお知らせは[pmikorea.kr](https://pmikorea.kr)で確認できます。 ## シーズン1を終えて 6月1日に申請書を出してから、ここまで4か月かかりました。人の体験記を読んでいた私が体験記を書くようになり、いまは一緒に勉強する場を手伝う側に立っています。 「PMP合格ロードマップ」は、ここでシーズン1を終えます。合格の記録と申請の流れ、試験の理解と勉強法、資格の比較と維持、そして合格のその後まで、全15回です。最後まで読んでいただき、本当にありがとうございました。 ### シーズン1 全記事一覧 **合格の記録と申請の流れ** 1. [PMP合格体験記 第1部：7週間の準備と、Study Hall 60%台からPASSまで（費用・日程まとめ）](/ja/posts/pmp-pass-review-part-1) 2. [PMP合格体験記 第2部：試験当日の時間配分と、合格のための最後のアドバイス](/ja/posts/pmp-pass-review-part-2) 3. [PMPの受験申請からPearson VUEの予約まで：6月1日に申請、6月13日に予約完了（実際のメールを公開）](/ja/posts/pmp-application-pearson-vue-booking) 4. [PMP経歴の書き方とAudit（監査）：6月1日申請→6月9日承認、私のPM経歴はこうまとめました](/ja/posts/pmp-experience-application-audit) **試験の理解と勉強法** 5. [2026年PMP試験改定まとめ：変わったこと、そしてPMBOK第7版 vs 第8版](/ja/posts/pmp-2026-exam-changes-pmbok-8) 6. [PMP間違いノートの書き方：間違えた問題を「判断ルール」に変える6ステップ（無料Wordテンプレート付き）](/ja/posts/pmp-error-log-method) 7. [GPTで概念を確認し直し、NotebookLMの音声で通勤復習：私のPMP AI勉強ルーティン](/ja/posts/pmp-gpt-notebooklm-study) 8. [通勤時間のPMP勉強法：短く濃く、こまめに見る（＋合格者の単語帳）](/ja/posts/pmp-commute-study-vocabulary) 9. [PMPケーススタディ問題の対策：2026年の新形式は、こう読んでこう解く](/ja/posts/pmp-case-study-questions) **資格の比較と維持** 10. [PMP vs CAPM vs PMI-ACP 比較：自分に合うのはどれ？（2026年版）](/ja/posts/pmp-vs-capm-vs-pmi-acp) 11. [3年で60PDU、私のPMP維持計画：最初のPDU承認メールから公開します](/ja/posts/pmp-60-pdu-renewal-plan) **合格、その後** 12. [PMP取得後、仕事で変わったこと：資格よりも「話し方」が変わった](/ja/posts/pmp-what-changed-at-work) 13. [PMPは、PMではない人にこそ効く：開発者やデザイナーがPMの目で働くとき](/ja/posts/pmp-for-non-project-managers) 14. [PMPって、結局効果ある？実務・年収・採用での優遇まで正直にまとめました](/ja/posts/is-pmp-worth-it-salary-benefits) 15. PMI韓国支部 教育委員会でのボランティア（いま読んでいる記事） シリーズページでまとめて読むこともできます。[「PMP合格ロードマップ」をすべて見る](/ja/series/pmp-roadmap) いまPMPを準備しているすべての方を応援しています。いつか支部の勉強会でお会いできたらうれしいです。 ## 参考資料 - [PMI韓国支部（PMI South Korea Chapter）](https://pmikorea.kr) - [PMI, Continuing Certification Requirements (CCR) Handbook (PDF)](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/ccr-certification-requirements-handbook.pdf) - [PMI, Project Management Professional (PMP)](https://www.pmi.org/certifications/project-management-pmp) --- # PMPって、結局効果ある？実務・年収・採用での優遇まで正直にまとめました > PMP合格から3か月の私がまとめた、PMPの効果。PMI給与調査第14版の年収中央値17%の差、韓国データの限界、韓国の求人事例とIBK・KTの優遇説、費用対効果まで。 _Slug: is-pmp-worth-it-salary-benefits · 2026-10-01_ PMPの準備をしていると、最後にはこの問いの前に立つことになります。で、結局効果はあるの？　今回は、実務、年収、採用に分けて、私の経験と確認できた数字だけで答えてみます。 **3行まとめ**：実務では共通言語と構造という効果がはっきりありましたが、年収については、PMIの調査でPMP保有者の年収中央値が17%高いと出ているだけで、韓国だけを切り出した数値は公開されていません。韓国国内では、公共機関のIT職やITの経験者採用の求人で、PMPを応募資格、書類選考の点数、優遇事項として使う事例を確認できましたが、IBK企業銀行（IBK기업은행）・KTの優遇説は求人からは確認できませんでした。プロジェクト経験を積んできた人には効果が確実で、まだ経験が足りないならCAPMから始めるほうがいいでしょう。 まず私の立場をはっきりさせておきます。私はまだ、PMPを持って転職市場に出たことがありません。なので、この記事には「年収が上がった」とか「オファーをもらった」という話は出てきません。PMPが市場で実際にどれくらい通用するのかは、自分で確かめて、この記事にそのまま追記します。 ## まず私の考え：経験者にははっきり効く 合格したのは7月なので、まだ3か月も経っていません。自分の結果で証明することはできませんが、2つのことにはかなり確信があります。 1つ目に、経験者にははっきり役立ちます。採用担当者は、初めて会う人の経歴を短い時間で判断しなければなりません。PMPは、「少なくとも数年間プロジェクトを率いてきて、その経験をPMIの基準で申告し、試験にも合格した」という要約です。履歴書のいちばん上にある3文字が、その説明を代わりにしてくれます。 2つ目に、韓国ではPMという職務が、ようやく専門職として定着しつつある段階だと私は見ています。だから、PMの能力を客観的に示す基準が必要な場面で、PMPが優遇資格や応募資格として使われるのです。このあと見る求人の事例が、まさにその姿です。 ## 実務での効果：共通言語、構造、信頼 実務での効果は[第12回](/ja/posts/pmp-what-changed-at-work)と[第13回](/ja/posts/pmp-for-non-project-managers)で詳しく書いたので、ここでは短くまとめます。 - **共通言語**：スコープ、変更要求、リスクと課題、受け入れ基準を同じ意味で使うようになります。国や会社の違う人たちと働くほど、差は大きくなります。 - **構造**：課題を前にしたら行動より先に評価し、変更は記録で受け、予測型とアジャイルのどちらをどこに使うかを選ぶ基準ができます。 - **信頼**：グローバルなクライアントやベンダーにとって、PMPは説明のいらない標準です。初対面の場で「この人は同じ枠組みで仕事をする」というシグナルになります。 - **PMではない人には、さらに大きく**：開発者、デザイナー、マーケターが意思決定者の言葉で話せるようになります。 ただ、これらの効果は数字で証明しにくいものです。私はこれを「確実だけれど測りにくい効果」と呼んでいます。では、測れるほう、年収から見ていきましょう。 ## 年収：数字が語ること、語らないこと PMIは、プロジェクトマネジメントの給与調査レポート（Earning Power）を出しています。最新の第14版は2025年11月に公開され、21か国の14,628人が2025年3〜4月に回答しました。 | 項目 | PMI Earning Power 第14版 | |---|---| | PMP保有者 vs 非保有者 | PMP保有者の年収中央値が17%高い | | 米国：PMP保有者 / 非保有者 | $135,000 / $109,157 | | 米国：PMP取得10年以上 / 5年未満 | $173,000 / $123,000 | 数字だけ見ると、かなり魅力的です。ただ、読むときには3つのことをぜひ覚えておいてください。 - **回答者が自己申告した年収です**。アンケートに答えた人たちの数字であって、給与明細を集めたデータではありません。 - **PMP保有者は、そもそも経験を積んだ人たちです**。学士の場合、36か月以上プロジェクトを率いていないと受験すらできないからです。なので17%は、「PMPを取れば年収が17%上がる」ではなく、「PMP保有者という集団の年収中央値が17%高い」と読むべきです。 - **10年以上と5年未満の差も同じです**。資格を長く持っている人は、そのぶんキャリアも長いのです。資格を持っている期間だけの効果とは言えません。 ちなみに、ネットでよく見かける「PMP保有者は33%多く稼ぐ」というのは、以前の版の数字です。今引用すべきなのは、第14版の17%です。 ### 韓国は？　公開されたPMPプレミアムはない 第14版の国別の詳細データは会員限定です。公開されている資料のなかで韓国の数値を確認できるのは、2023年に出た第13版です。 | 項目 | PMI Earning Power 第13版（2023年）韓国 | |---|---| | 韓国の回答者 | 130人 | | 全体の年収中央値 | US$65,363 | | PMP保有者の年収中央値 | US$66,857 | | PMP非保有者の年収中央値 | 回答者が少なすぎるため非公開 | 全体の中央値とPMP保有者の中央値の差を「韓国のPMPプレミアム」と呼んではいけません。全体の中央値にはPMP保有者も含まれていますし、本来比べるべき非保有者の数値は公開されていないからです。 まとめると、韓国でPMPが年収を何%上げるという公開された根拠は、まだありません。そういう数字を見かけたら、まず出典を確認してみてください。 ## 採用：韓国の求人でPMPはどう使われているか 年収の数字より現実的なのは、求人です。韓国の求人は一般に、必須の応募資格と「優遇事項」（우대 사항）を分けて載せていて、公共機関のなかには書類選考で資格を点数化するところもあります。韓国の求人を確認してみると、同じ「PMP優遇」でも重みがまったく違いました。大きく3段階に分かれます。 1. **応募資格**：この資格（またはリストのうちひとつ）がないと応募できない。 2. **書類点数**：書類選考の点数に直接反映される。 3. **優遇事項**：優遇事項のリストに入っている。 確認できた事例は次のとおりです。 | 機関・企業 | 求人 | PMPの使われ方 | |---|---|---| | 公務員年金公団（공무원연금공단） | 2025年 新規職員採用（電算職）、2025年9月1日〜9月15日 | 応募資格を満たす資格のひとつ。書類選考の資格点数（100点満点）のうち、事業管理分野で20点 | | 韓国資産管理公社（한국자산관리공사、KAMCO） | 2024年 新入職員（5級・IT） | PMPを含むIT資格リストのうち1つの保有が応募資格 | | kt cloud（KTグループ） | 2024年下半期 経験者採用、クラウド提案コンサルティング | 優遇：IT/Cloud分野の関連資格保有者（PMP/PMBOK/…） | | kt cloud（KTグループ） | 2024年下半期 経験者採用、クラウド遂行管理 | 優遇：国内外のCSP資格の保有（PMP/PMBOK/…） | | 韓国学中央研究院（한국학중앙연구원） | 2025年 専門職（電算）、2025年3月 | 優遇：PMP、IT-PMP、TOPCITレベル3以上、情報管理技術士 | このほか、KOTRA（大韓貿易投資振興公社）の2021年の経験者採用（ソフトウェアアーキテクト）の求人にも「PMP・CISA」の優遇がありましたが、古い求人なので参考程度に挙げておきます。 共通点が見えますか？　電算、IT、クラウドの提案・遂行管理のように、IT関連の事業を管理する職務です。そして公共機関では、優遇の域を超えて、応募資格や点数として使われることもあります。 ### IBK企業銀行とKTは？ 正直に言うと、私もIBK企業銀行やKT（韓国の通信会社）はPMPを優遇しているものだと思っていました。ところが、求人を自分で確認してみると、根拠は見つかりませんでした。 - **IBK企業銀行**：2026年下半期の新入行員採用（受付は2026年8月28日〜9月14日、175人）の資格加点リストに、PMPはありません。2024年下半期のリストにもありませんでした。2026年に「IT事業管理（PMO）専門家」の専門契約職の求人がありましたが、優遇事項の詳細は確認できませんでした。 - **KT**：KT本社の求人のなかに、PMPに触れたものは見つかりませんでした。確認できたのは、グループ会社であるkt cloudの経験者採用の求人です。 「どこそこが優遇しているらしい」という話は、こうして簡単に広まります。私と同じように信じていたなら、応募しようとしている会社の求人の原文を自分で開いてみてください。特に、経験者採用、PMO、IT事業管理、公共機関の電算職の求人を見るといいでしょう。同じグループ、同じ会社でも、職務や年度によって変わります。公共機関の求人は、ジョブ・アリオ（잡알리오）のような公共機関の採用情報サイトにまとまっています。 ## 費用対効果：私が実際に使ったお金 効果を考えるなら、費用も見る必要があります。領収書ベースで、私が使ったお金は次のとおりです。7週間の勉強の過程は[合格体験記の第1部](/ja/posts/pmp-pass-review-part-1)にまとめました。 | 項目 | 金額 | メモ | |---|---|---| | PMI Study Hall Essentials（3か月サブスクリプション） | $53.90 | $49 + 税$4.90、2026年6月1日決済（現在は3か月$59） | | PMP受験料（会員価格） | $445.50 | $405 + 税$40.50、2026年6月12日決済 | | 合計 | $499.40 | 会員費とオンライン講座の費用は別 | PMIからのPMP受験料の決済メール。2026年6月12日に購入したPMP Exam $405.00、税$40.50、合計$445.50が見え、注文番号は隠してある *2026年6月12日に受け取ったPMP受験料の決済メールです。注文番号は隠しました。* これとは別に、PMIの会員費がかかります。現在の韓国ストアでの定価は$139です。それでも会員として受験したほうが得な理由はシンプルです。受験料は非会員$655、会員$405と$250も差があり、会員費より大きいからです。再受験料も会員のほうが$100安く（会員$275、非会員$375）、3年後の更新料も$90安くなります。 ### 維持費用：3年で$60と60PDU PMPは取ったら終わりではありません。3年ごとに60PDUを満たし、更新料を払う必要があります。更新料は会員$60、非会員$150です。PDUは無料のウェビナーやeラーニング、支部の活動でも満たせるので、お金よりも時間と習慣の問題に近いです。私の最初のPDU（1.00PDU）は、9月3日に承認されました。 PMIからのPDU申請の承認メール。2026年8月31日に視聴したウェビナーWhy Some Projects Fail: The Sponsor’s Roleで、Ways of Working 0.25、Power Skills 0.25、Business Acumen 0.50、合計1.00PDUが承認されている *2026年9月3日に承認された最初のPDU申請です。8月31日に視聴したPMIのウェビナーで1.00PDUを取得しました。PMI IDと申請IDは隠しています。* 3年間でPDUをどう満たすかは、[第11回](/ja/posts/pmp-60-pdu-renewal-plan)で計画を立ててあります。 まとめると、私の場合、試験までに約$500と会員費、講座費、そして7週間分の仕事終わりの時間と週末がかかりました。この費用を無駄にしないためには、次のどちらかに当てはまる必要があると思います。PMPが求められるポジションを実際に狙うか、学んだ考え方を毎日の仕事で使うか。 ## 結論：効果が確実な人、まだそうとは限らない人 ### こんな人には効果が確実です - 学士の場合で3年以上プロジェクトを率いてきて、経験者としての転職や、PM・PMOの職務を目指している人 - 公共機関の電算職、IT事業管理、クラウドの提案・遂行管理のように、求人に実際にPMPが登場する職務を狙っている人 - グローバルなクライアントやベンダー、海外のチームと働いていて、共通言語が必要な人 - 経験は十分あるのに、その経験を説明する枠組みが必要な人 ### まだそうとは限りません - **プロジェクトを率いた経験がまだ足りない人**：そもそも受験資格を満たしません。[第10回](/ja/posts/pmp-vs-capm-vs-pmi-acp)で比較したCAPMの道が先です。 - **年収アップだけが目的の人**：韓国でPMPが年収をどれだけ上げるのか、公開された根拠がありません。 - **目標とする会社や職務の求人に、PMPが一度も出てこない人**：そのお金と時間を、職務そのものの力をつけることに使ったほうがいいかもしれません。 - **3年ごとに60PDUを満たすつもりがない人**：資格は維持してこそ意味があります。 ## おわりに：市場で自分で確かめて、また書きます 私の結論はこうです。PMPは、働き方には確実に効果がありましたし、公共機関のIT職やIT事業管理の分野の採用では実際に使われている資格です。ただ、年収を何%上げてくれるという韓国の根拠は、まだありません。PMPが市場で実際にどれくらい「売れる」のかは、自分で確かめて、この記事に追記します。 次回はシリーズの最終回です。PMI韓国支部（PMI Korea Chapter）の教育委員会でボランティアをしている話を書きます。ちなみに、支部でのボランティアは、PDUのGiving Backとしても認められます。 **次回**：[PMI韓国支部の教育委員会でボランティアを始めました](/ja/posts/pmi-korea-chapter-education-committee) ## 参考資料 - [PMI：プロジェクトマネジメント給与調査（Earning Power）](https://www.pmi.org/learning/careers/project-management-salary-survey) - [PMI公式：PMPの案内](https://www.pmi.org/certifications/project-management-pmp) - [PMI Study Hall Essentials](https://www.pmi.org/shop/p-/digital-product/pmp-pmi-study-hall-essentials-subscription/dp080) - [PMI CCRハンドブック：資格維持の要件（PDF）](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/ccr-certification-requirements-handbook.pdf) - 韓国の求人事例：公務員年金公団 2025年新規職員（電算職）、韓国資産管理公社 2024年新入職員（5級・IT）、kt cloud 2024年下半期経験者採用、韓国学中央研究院 2025年専門職（電算）、IBK企業銀行 2024年・2026年下半期新入行員採用の募集要項。求人は締め切り後に削除されることが多いため、リンクではなく求人名で残しておきます。 --- # PMPは、PMではない人にこそ効く：開発者やデザイナーがPMの目で働くとき > スコープ、ステークホルダー、リスク、変更管理、価値。PMPが整理した考え方は、開発者・デザイナー・マーケター・運用担当者にこそ大きな差を生みます。役割別の例からCAPMまで、現実的な道筋をまとめました。 _Slug: pmp-for-non-project-managers · 2026-09-30_ 今回は、少し挑発的な主張から始めます。PMPが整理した考え方は、PM（プロジェクト・マネージャー）よりも、PMではない人にこそ強力です。 **3行まとめ**：PMPの本当の価値は、資格そのものより、プロジェクト全体を見る視点にあります。開発者、デザイナー、マーケター、運用担当者がこの視点を身につけると、意思決定者の言葉で話せるようになり、だからこそ目立ちます。経験の要件を満たしていないならCAPMから、受験の予定がないならPMBOKガイド第8版の6つの原則から読んでみてください。 [前回](/ja/posts/pmp-what-changed-at-work)は、PMPを取ってから、PMである私の働き方がどう変わったかを書きました。今回は視点を逆にしてみます。同じレンズを、PMではない人が使ったらどうなるでしょうか。 ## PMの視点とは何か 私が言う「PMの視点」は、大げさなものではありません。自分の仕事を、プロジェクト全体のなかに置いて見る習慣です。PMPの勉強を通じて整理したレンズは、次の5つです。 | レンズ | 自分に投げかける問い | |---|---| | スコープ（Scope） | 今回の仕事はどこまでで、何はやらないと決めたのか？ | | ステークホルダー（Stakeholders） | この仕事で誰が影響を受け、誰が決めるのか？ | | リスク（Risk） | 何がうまくいかない可能性があり、そうなったらどうするか？ | | 変更管理（Change Control） | 変わったら何が揺らぎ、誰が承認するのか？ | | 価値（Value） | この仕事が終わったら、誰にとって何が良くなるのか？ | PMBOKガイド第8版の6つの原則にも、「全体的な視点（holistic view）」と「価値に焦点を当てる（focus on value）」が入っています。結局は同じ話です。自分の仕事だけを見るのではなく、それがどこにつながっていて、何を生み出すのかを見なさい、ということです。 ## なぜPMではない人にこそ強力なのか 理由は3つあると考えています。 **第一に、PMにとっては基本でも、ほかの職種では珍しいからです**。PMがスコープやリスクを口にするのは当たり前なので、たいして目立ちません。でも、開発者が同じことを言えば話は別です。珍しいからこそ、差になります。 **第二に、問題を最初に目にするのは現場の担当者だからです**。スコープがこっそり膨らんでいることに最初に気づくのはコードを書く人で、スケジュールが危ないと最初に感じるのは画面を描く人です。その人がPMの言葉で話せば、問題はずっと早い段階でテーブルに載ります。 **第三に、意思決定者はスコープ、スケジュール、コスト、リスク、価値の言葉で話を聞くからです**。技術的に正しい話でも、この言葉に翻訳されなければ、なかなか決定にはつながりません。「このライブラリはもうメンテナンスされていません」よりも、「このままだとセキュリティリスクが残り、今入れ替えるとスケジュールが2週間延びます。どちらで進めましょうか？」のほうが決定を引き出します。 PMではない人がPMの言葉を使えば、「PMのまね」ではなく「全体を見る実務者」になります。私は、こういう人こそチームで最も貴重だと思っています。 ## 役割ごとに描いてみると 以下の場面は実在の人物の話ではなく、説明のためにつくった架空の例です。 ### 開発者：黙って抱え込まず、変更要求として上げる スプリントの途中で、「このフィールドをひとつだけ追加してください」という依頼が来ます。人のいい開発者は、黙って引き受けます。残業で穴埋めし、テストはぎりぎりになり、スケジュールのリスクは誰にも知られないまま積み上がっていきます。 PMの目を持つ開発者は、同じ依頼にこう答えます。 ```text ご依頼の「配送メモ」フィールド追加の件、まず影響を共有します。 - スコープ：注文画面、管理画面、注文データの保存方法が変わります - スケジュール：今回のスプリントに入れると、決済テストが後ろにずれます - リスク：決済フローに手を入れるため、回帰テストが必要です - 選択肢：(A) 今回のリリースに含める (B) 次のスプリントに回す (C) スコープを縮小する どれで進めるか、ご判断をお願いします。 ``` このメッセージを送った瞬間、開発者は「仕事を断る人」ではなく「決定を助ける人」になります。変更要求（change request）に影響分析を添えたもので、PMP試験が正解として求める順番とまったく同じです。 ### デザイナー：好みではなく、価値とリスクで案を説明する 「A案のほうがきれいです」は説得ではなく、好みです。同じ案でも、こう説明すれば意思決定者の耳に届きます。 > A案は、新規顧客が初回購入までにたどるステップを減らします。そのかわり新しいコンポーネントが必要になるので、開発スコープが大きくなります。B案は既存のコンポーネントを再利用するので、スケジュールのリスクが低くなります。今期の目標が新規顧客のコンバージョンならA案を、ローンチ日程が優先ならB案をおすすめします。 選択肢を価値とリスクで並べ、判断基準まで提案すること。デザイナーがこう話せば、デザインレビューは「誰の好みが勝つか」から「何を得て、何を受け入れるか」に変わります。 ### マーケター：キャンペーンをひとつのプロジェクトとして見る PMBOKガイド第8版は、プロジェクトを「価値を創出するために、固有の文脈のなかで行う有期性のある取り組み」と定義しています。始まりと終わりがあり、毎回条件が違い、終わると何かを残す仕事。キャンペーンはまさにそれです。 キャンペーンをプロジェクトとして見ると、問いが変わります。ランディングページが開発のリリースに紐づいているなら、リリースが遅れたとき、すでに出稿した広告費はどうなるのか。注文が殺到したら、CSと物流は準備できているのか。ランディングページの「完了」の基準は何か。そして、このキャンペーンの成功は表示回数なのか、売上なのか、リピート購入なのか。 こうした問いをキャンペーン開始前に投げかけるマーケターは、開発チーム、CSチーム、物流チームの誰にとっても一緒に働きやすい同僚になります。 ### 運用担当者：まずリスク登録簿を1枚書く 運用担当者は、「去年もこうだったよね」をいちばんよく覚えている人です。その記憶を頭のなかだけにしまっておかず、1枚の表に書き出せば、リスク登録簿（risk register）になります。 | リスク | 発生確率 | 影響度 | 対応 | 担当 | |---|---|---|---|---| | 大型連休の直前に注文が集中し、出荷が遅れる | 中 | 高 | 出荷締め切り時刻の事前告知、追加人員の確保 | 物流 | | 決済代行会社の定期メンテナンスがプロモーションの時間帯と重なる | 低 | 高 | メンテナンス日程の事前確認、プロモーション時間の調整 | 運用 | | 在庫の同期が遅れ、品切れ商品が売れてしまう | 中 | 中 | 同期のモニタリング、品切れ処理の基準を合意 | システム | この表があれば、会議は「心配」から「決定」へと進みます。そして、現場をいちばんよく知る人が書いたリスク登録簿は、PMが机の上で書いたものより正確である可能性が高いのです。 ## 私の経歴がそうでした この主張に確信を持っているのは、私自身の経歴があるからです。私は最初からPMだったわけではありません。 - **大学**：ソウルの聖公会大学（성공회대학교）で、経営学とソフトウェア工学をダブルメジャー（複数専攻）で学びました（2014〜2021年）。一方はお金と顧客の言葉、もう一方はシステムの言葉でした。 - **起業**：2020年10月、FeelBetterという小さなEC事業を自分で立ち上げました。4か月で約5,000万ウォンの売上を出しました。 - **オンライン事業マネージャー**：2021年1月にiCOOP（Natural Dream）に入り、PM兼オンライン事業マネージャーとして、韓国の大手オンラインマーケットプレイスであるNAVER（ネイバー）とCoupang（クーパン）への出店を担当しました。営業、CS、SCM、WMS、デザイン、ITのあいだを調整し、SEOやキャンペーン、No PlasticのようなESGキャンペーンも手がけました。 - **PM**：2023年4月からはHyperhireでSoftware Development PMとして5か国の開発者と働き、2025年3月からはConcentrixでGlobal Tech PMとして働いています。 肩書きは変わり続けましたが、どのポジションでも役に立ったのは「PMの視点」でした。小さな事業をしていると、何を売って何を売らないかが、そのままスコープになります。マーケットプレイスへの出店は、営業からITまで6つの流れの仕事が絡み合うプロジェクトでした。振り返ってみれば、PMという肩書きとは関係なく、私はずっとプロジェクトをやっていたわけです。 PMPは、その視点に名前と順番を与えてくれた試験でした。だから私はPMPを、「PMになるための資格」というより、「PMのように考える方法をまとめた教科書」だと考えています。 ## PMではない人のための現実的な道筋 考えるだけで終わらせないためには、今の自分の立場でできることから見ていけばいいのです。 ### 1. まずPMPの受験資格を確認する PMPは、経験がなければ受験できない試験です。2026年に改訂された試験内容概要（ECO）の要件は次のとおりです。 | 最終学歴 | 必要なプロジェクトを率いた経験 | |---|---| | 高校卒業 | 60か月 | | 短大卒（準学士）または職業教育課程（EQFレベル5、2026年新設） | 48か月 | | 学士 | 36か月 | | PMI GAC認定の学位 | 24か月 | いずれの場合も、経験は直近10年以内に積んだものでなければならず、プロジェクトマネジメントの研修35時間も必要です。私が申請したときはこの期間が8年で、学士の基準（36か月）で受験資格を満たしました。 韓国からアクセスしたPMIのPMP案内ページ。3+ years of experience leading projectsという文言と、会員価格$405、通常価格$655、Apply Nowボタンが見える *韓国からアクセスしたPMIのPMP案内ページです。タイトルのすぐ下に「3+ years of experience leading projects」と書かれています。* PMではない方がここで必ず見ておくべき単語は「leading」です。PMIが経験の記述で見る核心は、プロジェクトをどう率いたかです。プロジェクトごとに、目的と期間、どう率いたか、誰と働いたか、どんな活動を主導したか、結果はどうだったかを書く必要があります。逆に、定型的な運用業務や単なる事務作業は認められず、期間が重なるプロジェクトは、重なった月を1回分しか数えません。 ですから、肩書きがPMでなくても、プロジェクトで何を率いたのかを具体的に説明できるなら、検討する価値はあります。経験の書き方は[第4回](/ja/posts/pmp-experience-application-audit)で詳しくまとめました。 研修35時間の基準がまもなく変わります。2026年12月1日からは、ライブ授業はPMI認定教育機関（ATP）、中国のREP、認定を受けた高等教育課程で受けたものだけが認められます。セルフペース（self-paced）のオンライン講座は提供元を問わず引き続き認められますが、本や模擬試験だけでは認められません。有効なCAPMを持っていれば、35時間の要件そのものが免除されます。 ### 2. 経験がまだ足りないならCAPM 経験が足りないからといって、ただ待っている必要はありません。PMIの入門資格であるCAPMなら、実務経験は必要ありません。高校卒業以上、18歳以上、プロジェクトマネジメントの研修23時間で受験資格を得られます。試験は150問（採点対象135問、採点対象外15問）、3時間、休憩1回で、受験料は会員$225、非会員$300です。 CAPMの本当のメリットは、その次のステップにあります。のちにPMPを受験するとき、CAPMが有効であれば研修35時間の要件が免除されます。今勉強したことが、そのまま次の階段になるわけです。PMP、CAPM、PMI-ACPのどれが合っているかは、[第10回](/ja/posts/pmp-vs-capm-vs-pmi-acp)で表にして比較しました。 ### 3. 受験の予定がなくても：PMBOKガイド第8版の原則から すぐに試験を受けるつもりがなくても、読んでおく価値のあるものがあります。2025年11月に出たPMBOKガイド第8版の6つの原則です。 - 全体的な視点（Holistic view） - 価値に焦点を当てる（Focus on value） - 品質を組み込む（Embed quality） - 説明責任のあるリーダーシップ（Accountable leadership） - サステナビリティを統合する（Integrate sustainability） - エンパワーされた文化（Empowered culture） たった6行ですが、開発者でもデザイナーでも、自分の仕事にすぐ当てはめてみられる文章です。PMI会員なら第8版のPDFは無料です。第7版から何が変わったかは[第5回](/ja/posts/pmp-2026-exam-changes-pmbok-8)にまとめました。 今日すぐに試せることもあります。次の会議に入る前に、さきほどの5つの問いをメモのいちばん上に書いて持っていってみてください。スコープ、ステークホルダー、リスク、変更、価値。そのうちひとつを会議で口にするだけでも、会話の質が変わります。 ## おわりに PMPはPMのための資格ですが、PMの視点は誰のものにもなりえます。むしろ、PMではない人がこの視点を持つときにこそ、差は大きく出ます。私は肩書きが変わるたびに、それを感じてきました。 次回は、いちばん現実的な問いを扱います。PMPは年収や採用に本当に役立つのでしょうか。PMIの給与調査の数字と、韓国国内の求人を実際に確認した結果をまとめました。 **次回**：[PMPって、結局効果ある？実務・年収・採用での優遇まで正直にまとめました](/ja/posts/is-pmp-worth-it-salary-benefits) ## 参考資料 - [PMP Examination Content Outline 2026（PDF）](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf) - [PMI公式：PMPの案内](https://www.pmi.org/certifications/project-management-pmp) - [PMI公式：CAPMの案内](https://www.pmi.org/certifications/certified-associate-capm) - [PMI：PMBOK®ガイド](https://www.pmi.org/standards/pmbok) - [PMI Certification Handbook（PDF）](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/generic-certification-handbook.pdf) --- # PMP取得後、仕事で変わったこと：資格よりも「話し方」が変わった > PMP合格から3か月近く、グローバルテックPMとして働くなかで変わった習慣をまとめました。スコープ・変更要求・リスクといった共通言語、行動前の評価、価値中心の考え方、ハイブリッドのテーラリングまで。 _Slug: pmp-what-changed-at-work · 2026-09-28_ [前回](/ja/posts/pmp-60-pdu-renewal-plan)は、PMPを3年間維持するための60PDUの計画を立てました。では、この資格は維持するだけの価値があるのでしょうか。今回は、その問いの半分にあたる実務の話をします。 **3行まとめ**：PMPが変えたのは、知識の量よりも仕事の順番でした。同じ言葉を同じ意味で使い、課題を前にしたらまず評価し、変更は記録で受け、成果物よりも価値を問うようになりました。ただ、合格してからまだ3か月も経っていませんし、資格が仕事を代わりにやってくれるわけではありません。 この記事には、クライアント名も、特定の会議の場面も出てきません。クライアントの情報を守る必要があるのはもちろんですが、何より「あの日何があったか」より「最近どう働いているか」を整理したかったからです。本文の例は、説明のためにつくった架空の状況です。 ## まずは私の仕事環境から 今、私はConcentrixでGlobal Tech PMとして働いています。エンタープライズのクライアント向けに、Shopify・MagentoでのEC構築と機能改善を担当し、優先順位の整理からリスク管理、UAT（ユーザー受け入れテスト）、リリース、ローンチ直後の安定化までを見ています。 仕事で関わるのは、クライアント企業の本社チーム、各国の現地法人、グローバルベンダー、海外の技術チームです。規模感をひとつ例に挙げると、あるグローバルなビューティーグループのPDP（商品詳細ページ）生成SaaSを改善し、5つのブランド、27のECサイトへと広げる仕事を担当しました。ひとつの決定が、複数のブランドと複数の国へ一度に広がる構造です。 その前は、HyperhireでSoftware Development PMとして、Web、アプリ、SaaS、ブロックチェーンのプロジェクトを担当していました。一緒に働いた開発者は、インド、パキスタン、インドネシア、ナイジェリア、エチオピアにいました。国は5つ、タイムゾーンもバラバラでした。 こうした環境で仕事がうまくいかなくなるきっかけは、たいてい技術よりも言葉にある、と私は考えています。だから、PMP以後に変わったことも、ほとんどが「言葉」と「順番」でした。 ちなみに、これらはすべてPMPを取る前からやってきた仕事です。資格を取ったから仕事の中身が変わったのではなく、同じ仕事のやり方が少しずつ変わったのです。 ## 最初に変わったのは言葉だった PMとして働くなかで、scope、change request、riskといった言葉は、PMP以前からずっと使っていました。ところがPMPの勉強を通じて、これらの言葉の境界が格段にはっきりしました。最近、グローバルな会議やメールで意識して使い分けているのは、次の5つです。 | 用語 | 私が使っている意味 | 使い分ける理由 | |---|---|---| | Scope（スコープ） | 今回やると合意したこと、そしてやらないと決めたこと | 「やらないこと」まで書いておかないと、あとで話が食い違う | | Change Request（変更要求） | 合意したスコープ・スケジュール・コストを変えようという正式な要求 | 小さく見えても影響があるなら、決定権者が判断すべき | | Risk（リスク） | まだ起きていないが、起こりうる不確実なこと | 前もって対応計画を立てられる | | Issue（課題） | すでに起きていて、今まさに影響を与えていること | 必要なのは計画ではなく、解決と報告 | | Acceptance Criteria（受け入れ基準） | 成果物を「完了」として受け入れる条件 | UATで「できたと思う」と「できた」を分ける | このなかで私にとって特に役立ったのは、リスクと課題の区別です。「This is a risk」と「This is an issue」は、聞き手にとってまったく別のシグナルです。前者は「備えよう」、後者は「今すぐ手を打とう」という意味になります。この2つを混ぜて使うと、相手はどれくらい身構えればいいのかわかりません。 母語の違う人たちが英語で一緒に働くとき、正確な単語ひとつが段落ひとつ分の働きをします。そしてPMPは世界中で同じ基準で行われる試験なので、これらの言葉は、国や会社が違っても同じ意味で通じる数少ない共通語に近いものです。 ## 課題と変更を前にして：まず評価、まず記録 正直に言うと、実務での私の本能は「とりあえず直そう」です。試験勉強中、[間違いノート](/ja/posts/pmp-error-log-method)に何度も書いたミスもその方向でした。原因を突き止める前に解決策を選び、影響を分析する前に実行してしまうミスです。 勉強中にNotebookLM（現 Gemini Notebook）でつくった韓国語の音声リストを見ても、同じことが言えます。タイトルに「실무 본능」（実務の本能）が2回、「PM도 틀리는」（PMでも間違える）が2回出てきます。通勤中に聴いていたこれらの音声のテーマは、結局のところ、実務の本能とPMPの正解とのギャップだったわけです。音声をどうつくり、どう聴いていたかは[第7回](/ja/posts/pmp-gpt-notebooklm-study)にまとめました。 NotebookLMのStudioパネルに並ぶ韓国語のディープダイブ音声の一覧。実務の本能がPMPのPeople領域で不正解になる理由、現役PMでも間違えるPMP変更管理の落とし穴など、約12〜24分の音声が見える *2026年6月、PMPの勉強中にNotebookLMでつくった韓国語の音声要約リストです。タイトルには「実務の本能」と「PMでも間違える」が2回ずつ入っています。* ### 課題が起きたとき ECでは、課題は予告なしにやってきます。リリース直後に、決済ステップでエラーの問い合わせが入りはじめたとしましょう。私の本能は、まず開発チームに「確認お願いします」と送るほうです。 最近は、そのメッセージを送る前に、まず3つのことを書き出します。 1. **影響**：誰が、どこで、どれくらい影響を受けているか。すべての国なのか、特定の決済手段なのか。 2. **性質**：すでに起きた課題なのか、まだ可能性にすぎないリスクなのか。 3. **知らせる人と決める人**：誰が知っておくべきで、誰が判断すべきか。 書き出すのは数分で十分です。その数分が、開発チームが見当違いの場所を探すのを防ぎ、クライアントと私が同じ絵を見られるようにしてくれます。 もちろん例外もあります。決済がまるごと止まったなら、評価より復旧が先です。[合格体験記の第1部](/ja/posts/pmp-pass-review-part-1)で書いたとおり、PMPのマインドセットにも、差し迫った危険のように即座の対応が必要な例外があります。ただ、急ぐときほど「どこまで、なぜ」を確かめる順番だけは手放さないようにしています。 ### 変更要求が来たとき ECの改善案件では、小さな要望がひっきりなしに来ます。ボタンの文言ひとつ、フィルターひとつ、国をひとつ追加。一つひとつは小さく見えても、QAや翻訳、国ごとのUATにまで響くことが少なくありません。 変更管理は、私が試験勉強で何度も間違えた分野でもあります。上のリストにも「현업 PM도 틀리는 PMP 변경관리 함정」（現役PMでも間違えるPMP変更管理の落とし穴、23分34秒）があります。タイトルのとおり、現場の感覚で解くと間違えやすい分野です。 だから今は、小さな要望ほど口頭だけでOKしないようにしています。最低でも、次の5行は残します。 ```text [変更要求] 例：商品詳細ページに配送案内バナーを追加 1. 要求：誰が、なぜ要求したか 2. 影響：スケジュール / コスト / スコープ / 品質（QA・UATのやり直し） / リスク 3. 選択肢：今回のリリースに含める / 次のリリースに回す / やらない 4. 決定権者：誰が承認するか 5. 決定：何を、いつ決めたか ``` PMP試験が正解として求める順番も同じです。影響を分析し、正式な手続きで承認を得て、承認されたら計画を直して共有する。最初は、細かすぎると思われないか気になることもあります。それでも記録が残っていれば、クライアントの担当者も自分の組織に変更を説明しやすくなります。変更要求書はPMを守る文書であり、クライアントの担当者を守る文書でもあるのです。 ## 成果物より価値を問う 私の音声リストには、「버그 없는 프로젝트가 인수를 거절당한 이유」（バグのないプロジェクトが受け入れを拒否された理由）というタイトルもあります。タイトルそのものが問いになっています。バグがないのに、なぜ拒否されたのでしょうか。私がこのタイトルから読み取る答えはこうです。つくると決めたものはつくったけれど、顧客がもともと得たかったものは届けられなかった。 PMの仕事をしていると、アウトプット（output）とアウトカム（outcome）を混同しがちです。「リリースした」「機能を公開した」はアウトプットです。クライアントがお金を払った理由は、その先にあります。運用が楽になること、顧客がもっと簡単に買えること、複数の国のサイトが同じ基準で動くこと。 だから最近は、要件を受け取るときに質問をひとつ付け加えます。 > これが公開されたら、誰が何を今よりうまくできるようになりますか？　それはどうやって確かめますか？ そして、その答えがUATの受け入れ基準に入っているかを確認します。機能が動くかどうかだけを確かめるUATと、もともと得たかった結果まで確かめるUATは別物です。 PMIも同じ方向に動きました。2026年に改定されたPMP試験の試験内容概要（ECO）は、PMBOKガイド第8版のプロジェクトの定義、つまり「価値を創出するために、固有の文脈のなかで行う有期性のある取り組み」をそのまま使っています。プロセス（Process）領域には「価値に基づくデリバリーの確保を支援する（Help ensure value-based delivery）」というタスクが新たに加わり、ビジネス環境（Business Environment）の比重は8%から26%に増えました。詳しい変化は[第5回](/ja/posts/pmp-2026-exam-changes-pmbok-8)にまとめています。 ## ベンダーとオフショアチーム：コントロールより支援 白状すると、私の試験結果では人（People）の領域がBelow Targetでした。3つの領域のなかでいちばん低い評価だった人間が「人との接し方が変わった」と書くのは、少し気恥ずかしいものがあります。 それでも、People領域の問題で私が繰り返し間違えたパターンははっきりしていました。チームと話す前にすぐ上にエスカレーションしたり、原因を見る前に人を替えようとしたりする選択です。PMIが求める答えは正反対でした。PMはチームをコントロールする人ではなく、チームを支援し、障害を取り除く人だということです。 この視点は、所属もタイムゾーンも違うチームと働くときにこそ役立ちます。今一緒に働いているグローバルベンダーは、私の直属のチームメンバーではありません。別の会社で、別の契約のもとで働いています。Hyperhire時代には、5か国の開発者たちと、それぞれ異なるタイムゾーンで働きました。こうしたチームに「なぜ遅れたんですか？」と聞く前に、まず「何が妨げになっていますか？」と聞くこと。私は、それがサーバント・リーダーシップの出発点だと考えています。 PMが取り除ける障害は、思っている以上に具体的です。 - **あいまいな要件**：質問を1日以上放置せずに答えるか、答えられる人にすぐつなぐ。 - **先送りされた決定**：クライアントの承認が必要なものは、相手チームの業務時間が始まる前に整理しておく。 - **権限と環境**：アクセス権限、テストデータ、ステージング環境など、開発者がひとりでは解決できないものを手配する。 - **揺れる優先順位**：何が先なのかを1行にまとめて共有する。 支援するというのは、基準を下げるという意味ではありません。むしろ、受け入れ基準を最初から明確に渡すことが、ベンダーにとってはいちばんの支援です。何をつくれば「完了」なのかわからないまま働くことほど、気力を奪われることはありませんから。 ## 予測型とアジャイル、どこに何を使うかを選ぶ感覚 私が手がけてきたエンタープライズのECプロジェクトは、その性質上ハイブリッドに近いものです。ローンチ日と予算は事前に承認されて固定されることが多く、UATとリリースは決められたゲートを通過しなければなりません。一方で、ローンチ後の改善要望や運用バックログは、優先順位が絶えず変わります。 PMPの勉強を通じて身についた感覚は、ハイブリッドを「両方を少しずつ」ではなく、「どこに何を使うかを選んだ結果」として見ることです。たとえばECのプロジェクトなら、こんなふうに分けてみる価値があります。 | 予測型で管理するもの | アジャイルで回すもの | |---|---| | ローンチ日程、予算、契約上のスコープ | 改善要望のバックログと優先順位 | | UATの日程と受け入れ基準、リリース承認 | スプリント単位の開発とデモ | | 国ごとのロールアウトの順番 | ローンチ後の安定化に関わる課題への対応 | 2026年に改定されたPMP試験も、約40%が予測型、60%が適応型（アジャイル）またはハイブリッドのアプローチを扱います。PMBOKガイド第8版では、テーラリングはもう原則のリストには入っていませんが、テーラリングの指針はそのまま残っています。私はこれを、「テーラリングはスローガンではなく、毎日下す判断だ」という意味だと受け取りました。 ## 履歴書の一行は変わったけれど PMPを取得してから、履歴書のいちばん上の行を「PMP® | Global Project Manager」に変えました。 PMIから届いたPMP取得のお祝いメール。You earned your Project Management Professional (PMP) Professional Certificationという文言と、Credlyのデジタルバッジの案内が見える *2026年7月4日の未明（韓国時間）に届いたPMP取得のメールです。Credlyのデジタルバッジは1〜2週間以内に別途メールで届く、と案内されています。* グローバルな協業では、この3文字が短い自己紹介の役割を果たすと思っています。初めて会う本社の担当者や海外のベンダーにとって、PMPはだいたいこんな意味に受け取られると思います。 - 一定期間以上、プロジェクトを率いた経験がある。学士なら36か月で、PMIは無作為に監査（Audit）も行う - PMIが定めた共通の用語と判断の枠組みを勉強している - 3年ごとに60PDUを満たさないと資格を維持できないので、学び続けている人だ ただ正直に言えば、まだ早いです。合格したのは7月なので、この記事を書いている時点で、まだ3か月も経っていません。だからこの記事には、「資格のおかげで起きたこと」をひとつも書きませんでした。3か月は、そういう話をするには短すぎます。 それに、資格が仕事を代わりにやってくれるわけではありません。私の履歴書に書いてある数字、たとえばグローバルな家電クライアントの運用バックログが104件から48件に減り、課題解決のリードタイムが27%短くなったことは、PMPという文字がつくった結果ではありません。現場でつくった数字です。PMPは、そうした仕事を説明する言葉を少しだけ正確にしてくれたにすぎません。 資格は会話のきっかけをつくってくれます。会話を続けさせるのは、結局のところ仕事です。 次回は、もう一歩踏み込んだ主張をしてみます。この考え方は、むしろPMではない人、つまり開発者やデザイナー、マーケターにこそ強力だという話です。年収や採用が気になる方のために、[第14回](/ja/posts/is-pmp-worth-it-salary-benefits)では数字と韓国国内の求人をもとにまとめています。 **次回**：[PMPは、PMではない人にこそ効く](/ja/posts/pmp-for-non-project-managers) ## 参考資料 - [PMI公式：PMPの案内](https://www.pmi.org/certifications/project-management-pmp) - [PMP Examination Content Outline 2026（PDF）](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf) - [PMIブログ：PMP試験の変更について（2026年7月10日）](https://www.pmi.org/blog/pmp-exam-change) - [PMI：PMBOK®ガイド](https://www.pmi.org/standards/pmbok) - [PMI CCRハンドブック：資格維持の要件（PDF）](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/ccr-certification-requirements-handbook.pdf) --- # 3年で60PDU、私のPMP維持計画：最初のPDU承認メールから公開します > PMPの資格維持ルール（3年で60PDU、教育35以上、Giving Back 25以下）と最初のPDU承認メール、年度別・タレント・トライアングル別の3年計画、申請とエビデンスの残し方をまとめました。 _Slug: pmp-60-pdu-renewal-plan · 2026-09-26_ PMPは、合格メールを受け取ったら終わりという資格ではありません。3年以内に60PDUを満たして更新しないと、PMPのままではいられません。私は合格から2か月ほどたった8月31日に、最初のPDUになったウェビナーを見ました。 **3行まとめ**：PMPは3年ごとに60PDUが必要で、そのうち教育（Education）が35以上、さらにタレント・トライアングルの3領域それぞれで8以上を満たさなければなりません。私の最初のPDUは8月31日に見たPMIのウェビナー1本で、9月3日に1.00PDUとして承認されました。私の3年計画は教育42にGiving Back 20を足した62PDUで、教育だけなら月1PDU強、ウェビナー1本分くらいです。 [第10回](/ja/posts/pmp-vs-capm-vs-pmi-acp)で3つの資格を比べたときに見たとおり、維持に必要なPDUはPMPが60といちばん多くなっています。今回は、その60を実際にどう満たすのか、最初のPDU承認メールから3年計画まで、そのままお見せします。 ## PMPの維持ルール（CCR）をひと目で PDU（Professional Development Unit）は、資格を維持するために積み上げる学習・貢献のポイントです。3年ごとにPDUをどれだけ、どんな種類で満たすべきかを定めたルールを、CCR（Continuing Certification Requirements）と呼びます。 | 項目 | 基準 | |---|---| | サイクル | 3年（PMPを取得した時点から） | | 必要なPDU | 60 | | Education（教育） | 35以上、そのうちWays of Working・Power Skills・Business Acumenで各8以上 | | Giving Back（貢献） | 最大25（そのうちWorking as a practitionerは最大8、1サイクルに1回） | | 繰り越し | サイクル最後の12か月に獲得したPDUのうち60を超えた分、最大20 | | 更新料 | 会員$60／非会員$150 | ### タレント・トライアングルの3領域 教育PDUは、PMIがタレント・トライアングル（Talent Triangle）と呼ぶ3つの領域に分かれます。 - **Ways of Working**：予測型、アジャイル、ハイブリッドといった働き方と、それに合った手法 - **Power Skills**：リーダーシップ、コミュニケーション、共感といった対人スキル - **Business Acumen**：プロジェクトを組織の戦略と結びつけて判断するビジネス感覚 3領域に8ずつ、合計24は必ず振り分けて満たす必要があり、残りの11はどの領域でもかまいません。教育は35を超えても上限はありませんが、Giving Backは25までしか認められません。つまり、**60のうち最低35は学んで満たす仕組み**です。 ## 最初のPDU：8月31日のウェビナー、9月3日に承認 私の最初のPDUは、PMIのウェビナー1本でした。8月31日に「Why Some Projects Fail: The Sponsor's Role」を見ました。PMPを勉強した人なら、タイトルを見ただけでスポンサー絡みの問題がいくつか思い浮かぶはずです。このウェビナーでPDUを申請したところ、9月3日に承認メールが届きました。 PMIのウェビナーWhy Some Projects Fail: The Sponsor's RoleがWays of Working 0.25、Power Skills 0.25、Business Acumen 0.50、合計1.00PDUとして承認されたことを知らせるPDU Claim Has Been Approvedメール *2026年9月3日に届いた最初のPDU承認メール。8月31日に見たウェビナーが1.00PDUとして認められました。PMI IDと申請番号は伏せています。* メールを見ると、ウェビナー1本が3つの領域に分けて計上されています。Ways of Working 0.25、Power Skills 0.25、Business Acumen 0.50で、合計1.00PDUです。領域ごとの最低8は、こうして少しずつ積み上がっていきます。 ### 資格を取ったあとも学びは続く 最初のPDUを受け取って、思ったことがあります。PMIは、資格を取ったあとも学び続けるように後押ししてくれる、ということです。会員なら無料で見られるウェビナーや講座が多く、それをこまめにチェックすることが、そのまま資格の管理であり勉強にもなります。受講した分だけPDUが自動で積み上がるか、簡単な申請だけで認められます。 試験対策のように歯を食いしばってする勉強ではないので、むしろ3年間コツコツ続けられそうです。 ## 私の3年計画：教育42＋Giving Back 20＝62 私のサイクルは、2026年7月にPMPを取得した時点から3年、つまり2029年7月ごろまでです。60ぴったりを目指すと、ひとつでも予定が狂えば最後に追い込まれるので、2PDUの余裕を持たせて62に設定しました。 | 区分 | 1年目（2026.7〜2027.7） | 2年目（2027.7〜2028.7） | 3年目（2028.7〜2029.7） | 合計 | |---|---|---|---|---| | Ways of Working | 4 | 4 | 4 | 12 | | Power Skills | 5 | 5 | 5 | 15 | | Business Acumen | 5 | 5 | 5 | 15 | | **Education小計** | 14 | 14 | 14 | 42 | | Giving Back：教育委員会でのボランティア | 4 | 4 | 4 | 12 | | Giving Back：Working as a practitioner | – | – | 8 | 8 | | **Giving Back小計** | 4 | 4 | 12 | 20 | | **合計** | 18 | 18 | 26 | 62 | 1年目の数字には、すでに受け取った1.00PDU（Ways of Working 0.25、Power Skills 0.25、Business Acumen 0.50）が含まれています。 ルールに合っているか検算すると、こうなります。 - 教育42：最低35を満たす - Ways of Working 12、Power Skills 15、Business Acumen 15：すべて領域ごとの最低8を満たす - Giving Back 20：上限25以下。そのうちWorking as a practitionerの8は上限8ちょうど - 合計62：60を満たす 数字を決めるときには、いくつか基準がありました。 - **Power Skillsは多めに**。試験でPeople領域がBelow Targetだったので、対人スキルは少し多めに積んでおくつもりです。 - **Giving Backは20まで**。25まで認められますが、学ぶ側を減らしたくありませんでした。 - **Working as a practitionerは3年目に**。1サイクルに1回しか申請できないので、最後の年にまとめて申請する予定です。 ### どこで満たすか | どこで | 分類 | 3年間の目標 | |---|---|---| | PMI会員向けウェビナー・eLearning | Education | 18 | | ProjectManagement.com | Education | 12 | | PMI韓国支部の月例セミナー・PMコラムセミナー | Education | 12 | | PMI韓国支部 教育委員会でのボランティア | Giving Back | 12 | | Working as a practitioner | Giving Back | 8 | | 合計 | | 62 | - **PMI会員向けウェビナーとeLearning**。会員なら無料で受講できるものがあります。年6PDUなら、2か月に1本のペースです。 - **ProjectManagement.com**。PMIのアカウントと連携しておけば、PDUが自動で登録されます。 - **PMI韓国支部のセミナー**。支部のイベントは教育PDUとして認められます。毎月のセミナーにはPDUが付き、隔月開催のオンライン「PMコラムセミナー」（PM 칼럼 세미나）は会員なら無料です。 - **教育委員会でのボランティア**。支部でのボランティアはGiving Backとして認められます。PMI韓国支部の教育委員会については、[第15回](/ja/posts/pmi-korea-chapter-education-committee)で改めてお話しします。 - **Working as a practitioner**。PMPに関連する仕事をしていること自体がGiving Backとして認められる項目です。最大8、1サイクルに1回です。 ## PDUの申請とエビデンス、こう管理します ### どこで：CCRS PDUは、PMIのCCRS（Continuing Certification Renewal System）に登録します。myPMIのダッシュボードから入れます。ProjectManagement.comのようにアカウントを連携しておけば自動で反映されるものもあれば、私の最初のウェビナーのように自分で申請して承認を待つ場合もあります。 ### 何を：エビデンスを残す PMIは、資格を取ったあとでも誰でも監査（Audit）の対象に選ぶことができます。そこで、PDUごとに少なくとも次のものは残しておくつもりです。 - 承認メール（上の最初のPDUのメールのようなもの） - 修了画面や出席確認のスクリーンショット - 日付、タイトル、主催者、取得したPDU - 何を学んだかの2〜3行のメモ - ボランティアは、いつ何をしたかの記録 ### いつ：締め切り直前にまとめない 60PDUを36か月で割ると、1か月に2もいきません（約1.7）。ところが最後の1年にまとめると、毎月5ずつ満たさなければなりません。そこで1年目と2年目にコツコツ積み上げ、3年目はWorking as a practitionerの申請と更新料の支払いで締めくくるつもりです。最後の12か月に60を超えたPDUは最大20まで次のサイクルに繰り越せるので、終盤に少し多めに取っても損にはなりません。 メールボックスに「PMP PDU」フォルダをひとつ作って、承認メールと修了画面のスクリーンショットをまとめておきましょう。3年後の更新のときに、エビデンスを探して慌てずに済みます。 ## おわりに PMPを取るのには7週間かかりましたが、維持は3年単位で続きます。短く濃かった7週間とは違って、これからの3年は細く長く続けていくつもりです。最初から読みたい方は、[合格体験記の第1部](/ja/posts/pmp-pass-review-part-1)からどうぞ。 次回は、PMPを取ってから実務で実際に何が変わったのかをお話しします。 **次回**：[PMPを取って実務で変わったこと：資格よりも「話し方」が変わった](/ja/posts/pmp-what-changed-at-work) ## 参考資料 - [PMI, Continuing Certification Requirements (CCR) Handbook (PDF)](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/ccr-certification-requirements-handbook.pdf) - [PMI, Project Management Professional (PMP)](https://www.pmi.org/certifications/project-management-pmp) - [PMI韓国支部（PMI 한국챕터）](https://pmikorea.kr) --- # ナクソンデ・ワンコプチャンのネジャンタン：ひとさじごとにコプがついてくる13,000ウォンの反則 > ナクソンデ駅4番出口から2分、コプチャン屋が煮込むネジャンタン。ひとさじすくうたびにコプがついてきて、エゴマの粉をひとさじ入れればもう勝負あり。接客まで親切だった木曜の夜の記録。 _Slug: nakseongdae-wang-gopchang-naejangtang · 2026-09-26_ 木曜の夜10時20分。腹は減っているし、明日は金曜だし、汁物が恋しい。 ナクソンデ（落星垈）駅4番出口から歩いて2分。看板からして自信満々の店に入った。名前は**ワンコプチャン**（왕곱창）。店名に「ワン（王）」をつけるということは、ふたつにひとつだ。本当に王様か、ただのハッタリか。 結論から言うと、この店は名前負けしていない。 **3行まとめ**：コプチャン屋が煮込むネジャンタン（牛モツのスープ、13,000ウォン）は、ひとさじごとに**コプ（小腸の中の脂）がついてくる**。テーブルにあるエゴマの粉をひとさじ入れれば、香ばしさが倍に。夜遅かったのに、接客が親切だった。 ## コプチャン屋のスープなら間違いない クッパ屋のネジャンタンとコプチャン屋のネジャンタンは、スタートラインが違う。コプチャン屋は、毎日コプチャンの下ごしらえをしている店だ。いい内臓がいちばん多く出入りする厨房で煮たスープなのだから、具がしょぼいはずがない。NAVER（ネイバー）プレイスについているひとこと要約も、まさにこうだ。「**新鮮さで武装した、臭みのないコプチャン**」。 メニュー表も、コプチャン屋という正体を隠そうとしない。
コプチャン盛り合わせ、コプチャンチョンゴル、コプチャン、マクチャン、テチャン、ポリャンの値段が書かれたワンコプチャンのメニュー表と、ビールの冷蔵庫
メニュー表の主役は、誰が見てもコプチャン。
コプチャン盛り合わせをいちばんおいしく楽しむ方法が書かれたポスターと、客による壁の落書き
「コプチャン盛り合わせをいちばんおいしく楽しむ方法」のポスター。コプチャンに本気の店だ。
| メニュー | 価格 | | --- | --- | | ソモリクッパ（牛頭肉のクッパ、テイクアウト可） | 12,000ウォン | | **ネジャンタン（テイクアウト可）** | **13,000ウォン** | | ヤンムチム（ミノの和え物） | 20,000ウォン | | コプチャン盛り合わせ（コプチャン・マクチャン・テチャン、2人前から） | 22,000ウォン | | コプチャン | 23,000ウォン | | コプチャンチョンゴル（ホルモン鍋、中／大） | 40,000ウォン／50,000ウォン | ## 主役、登板：ネジャンタン13,000ウォン
赤い油が浮いたスープに長ねぎ、白菜の外葉、春雨が入った土鍋のネジャンタン
ぐつぐつ煮立ったまま到着。ここまでは、ごく普通のネジャンタンの顔だ。
土鍋がぐつぐつと音を立てて運ばれてくる。赤い油がぷかぷか浮いたスープに、長ねぎ、ウゴジ（白菜の外葉）、春雨が絡み合っている。ここまでは、おなじみのネジャンタンだ。 ところが、スプーンを入れた瞬間に話が変わる。
スプーンの上に、コプがぎっしり詰まったコプチャンとミノ、春雨、長ねぎが一緒にすくい上げられている
ひとさじすくっただけで、コプチャンとミノが一緒に上がってくる。これがデフォルトだ。
ひとさじすくっただけで、**コプがぎっしり詰まったコプチャン**がついてくる。ミノも一緒に上がってくる。2さじ目も、3さじ目も。ふつうのネジャンタンは具を「発掘」するゲームなのに、ここでは具をよけてスープだけをすくうほうが難しい。 コプが本当にたっぷりだ。噛むほどに香ばしいコプがスープに溶け込み、ウゴジと春雨がそのスープをたっぷり吸い込む。ご飯1杯なんて、あっという間に消える。 ## ゲームチェンジャー：エゴマの粉ひとさじ
テーブルの上の、ふた付きの調味料入れに入ったエゴマの粉とスプーン
どのテーブルにもあるエゴマの粉。
ネジャンタンの上にエゴマの粉とこしょうをこんもりとのせたところ
エゴマの粉をひとさじ、こしょうをパラパラ。第2ラウンド開始。
どのテーブルにもふた付きの調味料入れがあって、中にはエゴマの粉が入っている。半分くらい食べたところで、山盛りひとさじ入れて、こしょうをパラパラと振ってみよう。スープがぐっととろみを増し、香ばしさが一気に立ち上がる。**同じスープひとつで、ふたつの味を楽しむ方法**だ。 ## おかずも、しっかり仕事をする
ステンレスのトレーにのったカクテキ、白菜キムチ、醤油漬け、醤油だれ
カクテキ、白菜キムチ、醤油漬け、そして具をつけて食べる醤油だれ。
カクテキ、白菜キムチ、大根・玉ねぎ・唐辛子の醤油漬け、そして具をつけて食べる醤油だれ。熱いスープの合間に、酸味のきいた醤油漬けをひとつずつつまむと、口の中がリセットされる。すくい上げたコプチャンを醤油だれにちょんとつけて食べるのもおすすめだ。 ## 壁がゲストブックの店
客の落書きで埋め尽くされた白い壁と、座卓が並ぶ奥の部屋
奥の座敷席。壁全体がゲストブックだ。
ステンレスの丸テーブルとドラム缶の椅子が並ぶコプチャン屋のホール
ステンレスの丸テーブルにドラム缶の椅子。王道のコプチャン屋の雰囲気。
奥の座敷席の壁は、客の落書きでびっしりだ。コプチャンのポスターの下には、誰かが店名で韻まで踏んでいる。「**왕 먹으니까! 왕 마싯따!**」（ざっくり訳すと「王（ワン）を食うから！　王（ワン）うまい！」）。その隣には「**ふたりで5人前を瞬殺**」という自白まで書いてある。ここまで来ると、インテリアというよりレビュー集だ。 ホールはステンレスの丸テーブルにドラム缶の椅子。王道そのままのコプチャン屋の風景だ。そして**接客がよかった**。夜10時を過ぎていたのに対応が親切で、最後のひとさじまで気持ちよく食べて店を出た。 ## 店舗情報 📍 **ワンコプチャン** · ソウル冠岳区ナクソンデヨッキル20（奉天洞1629-6） - 🚇 **アクセス**：2号線ナクソンデ駅4番出口から徒歩約2分 - 🕐 **営業時間**：月〜金 11:00〜翌01:00（ラストオーダー00:00）、土 11:00〜22:00、**毎週日曜定休** - 💰 **価格**：ネジャンタン13,000ウォン、ソモリクッパ12,000ウォン（どちらもテイクアウト可） - ✅ **設備・サービス**：テイクアウト、予約、団体利用、Wi-Fi - 🗺️ **地図**：[NAVERマップ](https://naver.me/xwmkwx0b) · [Googleマップ](https://www.google.com/maps/search/?api=1&query=37.4766602%2C126.9617088) メニュー価格と営業時間は、2026年9月に訪れたときのメニュー表とNAVERプレイスの情報だ。行く前に一度チェックしておこう。 ## Jaydenのひとこと評 > コプを探しに入ったら、コプに埋もれて出てきた。 - **コプ密度**：★★★★★ - **接客**：★★★★★ - **再訪**：あり。次はポスターに書いてあるとおり、コプチャン盛り合わせもしっかり味わってみるつもりだ。 --- # PMP vs CAPM vs PMI-ACP 比較：自分に合うのはどれ？（2026年版） > PMP・CAPM・PMI-ACPの受験資格、試験の構成、会員・非会員の受験料、再受験料、PDU、最近の改定を2026年時点で比較し、経験に応じてどれを選べばいいかをまとめました。 _Slug: pmp-vs-capm-vs-pmi-acp · 2026-09-24_ 第9回までは、PMPひとつだけを見て走ってきました。でもPMPについて調べていると、CAPMとPMI-ACPという名前もしきりに目に入ってきます。そこで3つの資格をひとつの表に並べて、誰にどれが合うのかを整理しました。 **3行まとめ**：プロジェクトを率いた経験が3年以上（学士の場合）ならPMP、経験が足りない人や職種を変えようとしている人はCAPM、PO（プロダクト・オーナー）やスクラムマスターのようにアジャイルチームで働く人はPMI-ACPが合います。韓国でのPMP受験料は会員$405、非会員$655で、取得後は3年ごとに60PDUを満たす必要があります。有効なCAPMがあればPMPの研修35時間が免除され、有効なPMPがあればPMI-ACPの実務経験要件を満たせます。 以下の価格と受験条件は、2026年時点でPMI公式ページとPMIストアに掲載されている内容です。条件も価格も変わることがあるので、支払いの前に必ず[PMP](https://www.pmi.org/certifications/project-management-pmp)、[CAPM](https://www.pmi.org/certifications/certified-associate-capm)、[PMI-ACP](https://www.pmi.org/certifications/agile-acp)の公式ページで改めて確認してください。 ## ひと目でわかる比較表（2026年時点） | 項目 | PMP | CAPM | PMI-ACP | |---|---|---|---| | 対象 | プロジェクトを率いた経験のある人 | 実務経験のない入門者 | アジャイルの実務者 | | 受験資格 | 学歴に応じた実務経験24〜60か月＋研修35時間 | 高卒以上＋プロジェクトマネジメントの研修23時間、18歳以上 | 高卒以上＋アジャイル研修21時間＋直近5年以内のアジャイル実務経験2年（代替条件あり） | | 試験 | 180問（採点対象170＋採点対象外10）、240分、休憩2回 | 150問（採点対象135＋採点対象外15）、3時間、休憩1回 | 120問（採点対象100＋採点対象外20）、3時間、休憩1回 | | 受験料（会員／非会員） | 韓国 $405／$655、米国 $425／$675 | $225／$300 | $435／$495 | | 再受験料（会員／非会員） | $275／$375 | $150／$200 | $335／$395 | | 維持条件（3年ごと） | 60PDU | 15PDU | 30PDU | | 最近の変更 | 2026年7月9日から新試験 | 2023年版の試験内容概要（ECO） | 2024年11月8日から新試験 | 表で見るとどれも似たようなPMI資格に見えますが、3つの資格が対象にしている人はかなり違います。PMPはプロジェクトを率いてきた人、CAPMはこれから始める人、PMI-ACPはアジャイルで働く人のための資格です。ひとつずつ見ていきましょう。 ## PMP：プロジェクトを率いてきた人の資格 私自身が取った資格なので、いちばん話せることが多いです。[合格体験記の第1部](/ja/posts/pmp-pass-review-part-1)でも書いたとおり、PMPは特定の業界やひとつの方法論に縛られません。プロジェクトを率いながら、人、プロセス、ビジネスの優先順位をまとめて扱えるかどうかが問われます。 ### 受験資格：学歴によって必要な経験が違う | 最終学歴 | 必要な経験（プロジェクトを率いた期間） | |---|---| | 高校卒業 | 60か月 | | 短大卒（準学士）または職業教育課程（EQFレベル5、2026年新設） | 48か月 | | 学士 | 36か月 | | PMI GAC認定の学位 | 24か月 | 経験は直近10年以内のものしか認められず、これとは別にプロジェクトマネジメントの研修35時間が必要です。有効なCAPMがあれば、この35時間は免除されます。 研修時間の扱いは、もうすぐ少し厳しくなります。2026年12月1日からは、ライブ講義はPMI認定教育機関（ATP）や認定を受けた大学の課程などで受けたものしか認められません。自分のペースで受けるオンライン講座（self-paced）はどこで受けても引き続き認められますが、本や模擬試験だけでは研修時間を満たせません。 経験の書き方や、監査（Audit）の対象になったら何を提出するのかは、[第4回](/ja/posts/pmp-experience-application-audit)にまとめています。 ### 試験：2026年7月9日から新試験 新しいPMP試験は、180問（採点対象170問、採点対象外10問）を240分で解き、途中に10分の休憩が2回あります。領域の比率はPeople 33%、Process 41%、Business Environment 26%です。問題の約40%は予測型、約60%はアジャイルまたはハイブリッドの状況です。何が変わったのかは[第5回](/ja/posts/pmp-2026-exam-changes-pmbok-8)で詳しく取り上げました。 ちなみに私は、改定直前の7月3日に旧試験（180問、230分）を受けました。 ### 受験料：韓国では会員$405、非会員$655 韓国からアクセスしたPMIのPMP資格ページ。会員価格$405、通常価格$655とApply Nowボタンが表示されている *韓国からアクセスしたPMIのPMPページ。会員価格$405、通常価格$655と表示されています。* PMIストアの価格は地域によって異なります。同じ試験でも、米国のストアでは会員$425、非会員$675です。私は2026年6月12日に、会員価格$405に税金$40.50を加えた**合計$445.50**を支払いました。支払いからPearson VUEの予約までは、[第3回](/ja/posts/pmp-application-pearson-vue-booking)に順を追ってまとめています。 再受験料は会員$275、非会員$375です。そして取得後は3年ごとに60PDUを満たす必要がありますが、これは[次回](/ja/posts/pmp-60-pdu-renewal-plan)、私の実際の計画でお見せします。 **PMI会員になるかどうか**。PMPなら、答えはほぼ決まっています。韓国での会員価格と非会員価格の差は$250で、会費は$139なので、受験料の割引だけで会費を差し引いても$111残ります。再受験は$100、更新は$90安くなり、PMBOKガイド第8版のPDFも無料でもらえます。一方、CAPM（割引$75）とPMI-ACP（割引$60）は、受験料の割引だけでは会費に届かないので、ほかの特典も含めて検討してください。 ## CAPM：経験なしで始められる入門資格 CAPM（Certified Associate in Project Management）は、実務経験がなくても受けられる入門向けの資格です。高校を卒業していて、プロジェクトマネジメントの研修を23時間受けていて、18歳以上であれば受験できます。 試験は150問（採点対象135問、採点対象外15問）を3時間で解き、休憩は1回です。試験内容概要（ECO）は2023年版です。受験料は会員$225、非会員$300、再受験料は$150と$200で、維持するには3年ごとに15PDUを満たせば大丈夫です。 私が思うCAPMの本当のメリットは、PMPへの架け橋になることです。**有効なCAPMがあれば、のちにPMPを受けるときに研修35時間が免除されます**。経験はまだ足りないけれど、いつかPMPを受けたいなら、まずCAPMで基礎を固め、そのあいだに経験を積むという順番もありです。 こんな人に向いています。 - 働き始めたばかりの新人や学生 - ほかの職種からPMへの転身を準備している人 - プロジェクト経験はあるものの、まだPMPの基準（学士なら36か月など）に届かない人 ## PMI-ACP：アジャイルチームで働く人の資格 PMI-ACP（PMI Agile Certified Practitioner）は、アジャイルの実務者のための資格です。スクラムマスター、プロダクト・オーナー（PO）、アジャイルチームのメンバーを思い浮かべるとわかりやすいでしょう。 受験には、高卒以上の学歴、アジャイル研修21時間、そして直近5年以内にアジャイルで働いた経験2年が必要です。経験の条件は、次のいずれかで代えることもできます。 - アジャイル経験1年＋PMI GAC認定の学位 - アジャイル経験1年＋他団体のアジャイル資格 - 有効なPMP 試験は2024年11月8日に新しくなり、120問（採点対象100問、採点対象外20問）を3時間で解きます。休憩は1回です。領域はMindset 28%、Leadership 25%、Product 19%、Delivery 28%で、マインドセットとリーダーシップを合わせると半分を超えます。受験料は会員$435、非会員$495、再受験料は$335と$395で、3年ごとに30PDUが必要です。 ここで注目したいのは、経験条件の最後の1行です。**有効なPMPがあれば、PMI-ACPの実務経験要件を満たせます**。PMPを取ったあと、アジャイルをもっと深く掘り下げたいなら、自然な次のステップになります。 ## 自分に合う資格の選び方 難しく考える必要はありません。いまの自分の状況から考えれば十分です。 | いまの状況 | おすすめ | 理由 | |---|---|---| | プロジェクトを率いた経験が3年以上（学士の場合） | PMP | 予測型・アジャイル・ハイブリッドを幅広く扱い、広く認められている | | 新人、学生、職種転換を準備中 | CAPM | 経験なしで受験でき、のちにPMPの研修35時間が免除される | | 経験はあるがPMPの基準に届かない | CAPM | 経験を積むあいだに基礎を固め、PMPにつなげる | | PO・スクラムマスターなどアジャイルチームの実務者 | PMI-ACP | アジャイルのマインドセット・リーダーシップ・プロダクト・デリバリーに特化 | | PMPを持っていて、アジャイルをさらに深めたい | PMI-ACP | 有効なPMPが実務経験要件を満たしてくれる | ひとつだけ覚えておいてください。3年という数字は学士の場合です。高卒なら、PMPに必要な経験は60か月、つまり5年です。 ### 迷ったときは アジャイルチームで働いていて、プロジェクトを率いた経験も3年を超えているなら、どちらの資格も受けられます。広く認められる資格がほしいならPMP、アジャイルの専門性をピンポイントで示したいならPMI-ACPです。PMPを先に取ればPMI-ACPの実務経験要件まで片づくので、順番としても悪くありません。 3つの資格は、こんなふうにつながることもあります。 > **CAPM**（経験を積むあいだ）→ **PMP**（研修35時間が免除）→ **PMI-ACP**（実務経験要件を満たす） ## 私がPMPを選んだ理由 理由はシンプルでした。eコマースとグローバルなソフトウェアデリバリーの分野で5年以上プロジェクトを率いてきたので、経験の条件は十分に満たしていました。そして、ひとつの方法論に縛られない幅広い資格、世界のどこでも通じる資格がほしいと思っていました。それがPMPでした。 PMという肩書きがなくてもプロジェクトを率いてきた人にとって、PMPがどんな力になるのかは、[第13回](/ja/posts/pmp-for-non-project-managers)で改めて取り上げる予定です。 ## 次回：取るよりも長い3年間 私はPMPを取るのに7週間かかりましたが、維持は3年単位で続きます。3年ごとに、PMPは60PDU、PMI-ACPは30PDU、CAPMは15PDUを満たす必要があります。次回は、私が受け取った最初のPDU承認メールと、3年間で60PDUを満たす計画をそのまま公開します。 **次回**：[3年で60PDU、私のPMP維持計画：最初のPDU承認メールから公開します](/ja/posts/pmp-60-pdu-renewal-plan) ## 参考資料 - [PMI, Project Management Professional (PMP)](https://www.pmi.org/certifications/project-management-pmp) - [PMI, Certified Associate in Project Management (CAPM)](https://www.pmi.org/certifications/certified-associate-capm) - [PMI, PMI Agile Certified Practitioner (PMI-ACP)](https://www.pmi.org/certifications/agile-acp) - [PMI, 2026 PMP Examination Content Outline (PDF)](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf) - [PMI, Continuing Certification Requirements (CCR) Handbook (PDF)](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/ccr-certification-requirements-handbook.pdf) --- # PMPケーススタディ問題の対策：2026年の新形式は、こう読んでこう解く > 2026年の改定で登場したPMPのケーススタディ問題を、PMIの公式情報と長いシナリオ問題の解き方からまとめました。読む順番、架空の練習ケース3問と解説、240分の時間配分まで。 _Slug: pmp-case-study-questions · 2026-09-22_ 最初に正直にお伝えすると、私はケーススタディ問題を試験会場で解いたことがありません。私が受けた2026年7月3日の試験は改定前のもので、ケーススタディのセクションは7月9日の新試験から始まったからです。 そこでこの記事では、2つのことを組み合わせました。PMIが公式文書で明らかにしている新しい問題形式の情報と、私が改定前の試験で長い状況設定問題を読んで解いていたやり方です。[第8回](/ja/posts/pmp-commute-study-vocabulary)が通勤中の勉強の話だったとすれば、今回は試験会場の中に入ります。 **3行まとめ**：ケーススタディは、表やグラフの付いた長いシナリオ1つに複数の問題が続く形式で、試験の最初のセクションに出てきます。まず今解く問題の問いを確認し、シナリオからアプローチ、ステークホルダー、数字、問いのタイプを見つけておけば、同じシナリオの次の問題が速く解けます。問題数は公開されていないので、1問あたり平均1分20秒のペースを守り、休憩を始めたら戻れないことを覚えておいてください。 試験改定の全体像（問題数、時間、ドメインの比重）は、[第5回：2026年PMP改定まとめ](/ja/posts/pmp-2026-exam-changes-pmbok-8)にまとめました。この記事では、そのうちケーススタディとグラフィックベースの問題だけを扱います。 ## PMIが公開しているケーススタディの情報 | 項目 | PMIの公式情報 | |---|---| | 形式 | 詳しいシナリオ（グラフやチャートが入ることもある）と、そのシナリオに付随する複数の問題 | | 出題位置 | 試験の最初のセクション | | 問題数 | 非公開。試験フォーム（form）ごとに異なる場合がある | | 同時に登場した形式 | グラフィックベースの問題：チャートやグラフなどの視覚資料を読み取って答える問題 | | 受験方式 | テストセンター試験とオンライン試験の両方で出題 | | 休憩 | ケースのセクションの直後に1回目の10分休憩。休憩を始めると、前のセクションには戻れない | | 全体の時間 | 180問を240分、1問あたり平均約1分20秒 | まとめると、PMIは形式と出題位置、休憩のルールまでは明らかにしていますが、問題数は公開していません。一部の対策サイトでは1ケースあたり2〜5問と紹介されていますが、PMIが確認した数字ではありません。 2026年版の試験内容概要（ECO）PDFの問題形式の説明には、ケース問題とグラフィックベースの問題の画面例が載っています。試験の前に一度は必ず見ておいてください。 翻訳版で受験するなら（私は韓国語で受けました）、もう一つ知っておいてほしいことがあります。各問題には、英語の原文を表示する「Exhibit」ボタンがあります。翻訳と英語が並んで表示されるわけではなく、ボタンを押して別に確認する方式です。長いシナリオで訳があいまいな文に出会ったら、原文を確認してみてください。 ## 長いシナリオは、こう読みます 改定前の試験も、大半は状況設定問題でした。[合格体験記の第2部](/ja/posts/pmp-pass-review-part-2)に書いたように、私は状況説明より先に最後の文の問いを見て、明らかに間違っている選択肢から消していきました。このやり方をケーススタディ向けに広げると、4つのステップになります。 ### ステップ1：まず問いを見る シナリオを精読する前に、今解く問題が何を聞いているのかを先に確認します。改定前の試験でも、最後の文が「最初に」なのか「次に」なのかを確認すると、問題の焦点がよく見えるようになりました。ケースはシナリオが長いので、この習慣の効果はもっと大きくなると思います。 ### ステップ2：シナリオから4つのことを探しておく | 探すもの | 手がかり | なぜ重要か | |---|---|---| | アプローチ | スプリント、バックログ、プロダクト・オーナー（PO）、レトロスペクティブが見えればアジャイル。ベースライン、変更管理委員会（CCB）、WBSが見えれば予測型。両方見えればハイブリッド | 正解がたどるべき手続きが変わります | | ステークホルダーと影響力 | スポンサー、顧客、規制当局、影響力の大きい人、反対している人 | 誰と先に話すべきかが決まります | | 制約と数字 | 期限、予算、規制、表やチャートの傾向 | グラフィックベースの問題と影響分析の根拠になります | | 問いのタイプ | `FIRST`、`NEXT`、`BEST`、`EXCEPT` | 同じ状況でも答えが変わります | ケースでは、同じシナリオに複数の問題が付いています。最初の問題でこの4つを見つけておけば、次の問題ではシナリオを最初から読み直さなくて済みます。特に`EXCEPT`（当てはまらないもの）は、合わない行動を選ぶ問題なので、いつもとは逆に考える必要があります。 ### ステップ3：PMIのマインドセットで選ぶ 選択肢が2つ残ったら、[合格体験記の第1部](/ja/posts/pmp-pass-review-part-1)でまとめたマインドセットに立ち返ります。ケースで特に役立ちそうな基準は、次の3つです。 - **行動する前に、状況を把握する**。原因と影響がわからないまま最も強い措置を選ぶと、不正解になることが多くありました。 - **エスカレーションより、まず協働**。チームやステークホルダーと先に話します。 - **合意した手続きに従う**。アジャイルの部分はPOとバックログで、予測型の部分は変更管理で処理します。 例外もあります。第1回に書いたように、倫理、法規、安全、差し迫ったリスクには、すぐに対処が必要な場合があります。 ### ステップ4：間違えた問題は間違いノートへ 間違えたケース問題も、[第6回](/ja/posts/pmp-error-log-method)の間違いカードに同じように記録します。原因タグ（C・R・M・S・A・T）を付けたうえで、ケースの場合は「シナリオで見落とした情報」を1行書き添えるのがおすすめです。アプローチの手がかりを見落としたならA、問いの条件を見落としたならR、時間に追われて当てずっぽうで選んだならTです。同じ種類の情報を見落とし続けるなら、読む順番を直すべきだというサインです。 ## 実際に解いてみよう：架空のケース 下のケースは、この記事のために自分で作った練習用の例です。実際のPMP試験やStudy Hallの問題ではなく、実際の試験の画面や形式とは異なる場合があります。 ### 状況：3か国のECサイト移行 あなたは、ある消費財メーカーのECサイト移行プロジェクトを担当するプロジェクト・マネージャーです。A国、B国、C国のサイトを新しいプラットフォームへ移行している最中です。 - サイトの画面と機能は、社内のスクラムチーム（開発者6人）が2週間のスプリントで作っています。プロダクト・オーナー（PO）は、本社のECチームの所属です。 - 既存の注文データと会員データの移行は外部ベンダーが担当し、スコープ・スケジュール・予算は承認済みのベースラインで管理しています。ベースラインを変更するには、変更管理委員会（CCB）の承認が必要です。 - リリース日は、8回目のスプリントが終わる日です。スポンサーであるコマース本部長は、この日付をすでに経営陣に報告しています。 - B国の現地法人社長は影響力が大きく、年末のプロモーションの前に、B国のサイトを必ずオープンさせるべきだという立場です。 **表1 スプリント別の進捗**（開始時点の全体バックログ240ポイント、単位：ストーリーポイント） | スプリント | 計画 | 完了 | 残りのバックログ | |---|---|---|---| | 1 | 40 | 38 | 202 | | 2 | 40 | 35 | 167 | | 3 | 40 | 30 | 137 | | 4 | 40 | 24 | 113 | **表2 データ移行作業の状況**（4回目のスプリント終了時点） | 指標 | 金額 | |---|---| | プランド・バリュー（PV） | $500,000 | | アーンド・バリュー（EV） | $450,000 | | 実コスト（AC） | $520,000 | ### 問題1 5回目のスプリントの計画ミーティングで、POがこう言います。「リリース日を守るには、今回も40ポイントを計画しなければなりません」。プロジェクト・マネージャーが最初に（`FIRST`）すべきことは何ですか？ - A. リリース日を守るため、40ポイントの計画をそのまま確定する。 - B. スポンサーに開発者の増員を依頼する。 - C. ベロシティが3スプリント連続で下がっている原因を、まずチームと一緒に把握する。 - D. リリース日を2スプリント後ろ倒しにして、スケジュールを組み直す。 ### 問題2（グラフィックベース） 表2をもとに、データ移行作業の状況を最も正確に（`BEST`）説明しているものはどれですか？ - A. スケジュールより進んでいて、予算も余っている。 - B. スケジュールより遅れていて、予算も超過している。 - C. スケジュールより遅れているが、予算は余っている。 - D. スケジュールどおりだが、予算を超過している。 ### 問題3 6回目のスプリントの途中で、法務チームから連絡がありました。B国で新しい個人情報保護の規制がリリース予定日より前に施行され、施行後は会員登録画面に別途の同意手続きが必要になるというものです。B国の現地法人社長は「スケジュールが先だから、リリースしてから直そう」と言っています。プロジェクト・マネージャーが次に（`NEXT`）すべきことは何ですか？ - A. B国の現地法人社長は影響力が大きいので、計画どおりにリリースし、規制への対応はリリース後に回す。 - B. 進行中のスプリントを止め、開発者たちに、まず同意機能を作るよう指示する。 - C. スポンサーに状況を引き渡し、決定が出るまで待つ。 - D. 法務チームと一緒に、規制がスコープとスケジュールに与える影響を分析し、POが必要な作業をバックログの優先順位に反映できるよう支援する。 ## 正解と解説 まず自分で解いてから、下へ進んでください。 ### 問題1の正解：C 表1の完了ポイントは38→35→30→24と、3スプリント連続で減っています。残り113ポイントを4回のスプリントで終えるには1スプリントあたり約28ポイントが必要ですが（113 ÷ 4 ≈ 28）、直近のベロシティは24ポイントです。原因がわからなければ、どんな対策が正しいのかもわかりません。まずはチームと一緒に、何がベロシティを下げているのか（障害、計画外の作業、技術的負債など）を確認する必要があります。 - Aは、チームの実際のベロシティを無視した計画です。スプリントにどれだけ入れるかは、チームが自分たちのキャパシティを見て決めます。 - Bは、原因がわからないまま、すぐにエスカレーションする選択です。人を増やしても、ベロシティがすぐに上がるわけでもありません。 - Dは、影響分析もステークホルダーとの合意もないまま、スケジュールのベースラインを変える行動です。このリリース日は、スポンサーが経営陣に報告した約束でもあります。 ### 問題2の正解：B - SPI = EV ÷ PV = 450,000 ÷ 500,000 = 0.90。1より小さいので、スケジュールより遅れています。 - CPI = EV ÷ AC = 450,000 ÷ 520,000 ≈ 0.87。1より小さいので、予算を超過しています。 差で見ても、SV（EV − PV）は−$50,000、CV（EV − AC）は−$70,000で、どちらもマイナスです。グラフィックベースの問題では、計算そのものより、どの数字をどこに入れるかでミスが起きます。SPIもCPIも分子はEV、ということさえ覚えておけば、半分は勝ったも同然です。 ### 問題3の正解：D 法規制の遵守は、交渉で動かせるものではありません。かといって、すぐに開発を指示するのも正解ではありません。規制が正確に何を求めていて、スコープとスケジュールにどんな影響を与えるのかを分析してはじめて、次の行動が決まります。 このプロジェクトはハイブリッドなので、進め方が2つあります。スクラムチームが作る画面の機能は、POがバックログの優先順位に反映し、リリース日のようなベースラインを変える必要があるなら、CCBの変更管理の手続きを経ます。分析の結果はスポンサーとB国の現地法人社長に共有し、期待値をあらためてすり合わせます。 - Aは、影響力のあるステークホルダーの要求とはいえ、規制違反を受け入れる選択なので不正解です。 - Bは、POを飛び越えて進行中のスプリントに作業を押し込む指示で、影響分析も抜けています。 - Cは、PMにできる分析をしないまま上に預けてしまう、受け身のエスカレーションです。スポンサーに上げるとしても、影響分析と選択肢を持っていくべきです。 第1回で、法規と安全の問題はすぐに対処が必要な例外だと書きましたが、この問題では規制がまだ施行前なので、影響を分析する時間があります。だから、分析してから手続きに沿って反映する、という順番が正しいのです。 ## 新試験の時間配分 240分で180問なら、1問あたり平均約1分20秒です。60問ずつに区切ると、ちょうど80分になります。 | 解いた問題数 | 使った試験時間（平均ペース） | |---|---| | 60問 | 約80分 | | 120問 | 約160分 | | 180問 | 240分 | この80分という数字は、私にとって少し特別です。改定前の試験で、私は最初の60問に約80分かかり、1回目の休憩で「このペースだと、後半で時間が足りなくなるのでは」と心配しました。230分の試験だったので、60問あたりの平均は約77分だったからです。同じ80分が、新試験ではちょうど平均ペースになります。 ケースのセクションは、次のように進めるのがおすすめです。 - セクションの問題数は事前にわからないので、セクション単位ではなく、1問1分20秒のペースで管理します。 - シナリオを読む時間は、どうしても最初の問題に集中します。同じシナリオの次の問題でその時間を取り戻せるので、最初の問題に時間がかかっても慌てないでください。 - セクションを終える前に、見直したい問題を整理しておきます。休憩を始めると、このセクションには戻れません。 - 10分の休憩は、思ったより早く過ぎます。第2回に書いたとおり、私は1回目の休憩で10分を少しオーバーしてしまいました。 ## 練習用の教材 - **PMI Study Hall**：商品ページの構成表に「Case Studies」が入っていて、2026年7月9日の新試験に合わせた商品だと案内されています。現在、Essentialsは3か月$59（四半期ごとに更新）で、フル模擬試験2回（各180問）、ミニ模擬試験10回、追加問題330問が含まれます。Plusは四半期$79で、フル模擬試験が3回です。会員と非会員で価格は同じで、英語のみの提供です。私が使ったのは改定前のバージョンなので、新しいケーススタディを自分で評価することはできません。私のStudy Hallの使用感は、[合格体験記の第1部](/ja/posts/pmp-pass-review-part-1)にあります。 - **2026年版ECOのPDF**：ケース問題とグラフィックベースの問題の画面例が載っています。無料で、形式を自分の目で確かめるには最も正確な資料です。 - **自分で作る練習**：改定前の問題でも、長い状況設定問題を選んで、この記事の4ステップで読む練習ができます。GPTにシナリオ形式の練習問題を作ってもらうこともできますが、正解と解説は必ず公式の資料で検証してください。GPTとNotebookLM（現 Gemini Notebook）の活用法は、[第7回](/ja/posts/pmp-gpt-notebooklm-study)にまとめています。 ## おわりに ケーススタディは新しい形式ですが、問われていることは以前と同じだと思います。まず状況を把握し、チームやステークホルダーと協働し、合意した手続きに従うプロジェクト・マネージャーかどうか。シナリオが長くなった分、読む順番を前もって決めておいた人が有利です。 次の第10回では、PMP、CAPM、PMI-ACPを比較します。実務経験がまだ足りない方や、アジャイル系の資格が気になる方の参考になるはずです。 **次の記事**：[第10回：PMP vs CAPM vs PMI-ACP](/ja/posts/pmp-vs-capm-vs-pmi-acp) **最初から読む**：[PMP合格体験記 第1部：7週間の準備と、Study Hall 60%台からPASSまで](/ja/posts/pmp-pass-review-part-1) ## 参考資料 - [PMI：PMP試験内容概要（ECO）2026、PDF](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf) - [PMIブログ：PMP試験改定のお知らせ](https://www.pmi.org/blog/pmp-exam-change) - [PMI：Project Management Professional（PMP）公式ページ](https://www.pmi.org/certifications/project-management-pmp) - [PMI Study Hall Essentials](https://www.pmi.org/shop/p-/digital-product/pmp-pmi-study-hall-essentials-subscription/dp080) - [PMI資格ハンドブック、PDF](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/generic-certification-handbook.pdf) --- # 通勤時間のPMP勉強法：短く濃く、こまめに見る（＋合格者の単語帳） > PMPの勉強は、一度に長くより、短くこまめに見るほうが記憶に残ります。通勤中の音声と単語帳での復習法、翻訳版の試験で用語が大事な理由、紛らわしい用語のペアと5分の単語ループをまとめました。 _Slug: pmp-commute-study-vocabulary · 2026-09-21_ [第1回](/ja/posts/pmp-pass-review-part-1)にも書きましたが、私は仕事帰りに長時間座って勉強できるタイプではありません。だから1日の勉強量をこなすことより、まったく勉強しない日を減らすことに集中しました。そのすき間を埋めてくれたのが、通勤時間でした。 **3行まとめ**：一度に長く見るより、短くこまめに見返すほうが記憶に残ります。私は通勤中に1本12〜24分のNotebookLM（現 Gemini Notebook）の音声を聞き、単語帳で用語を見直しました。英語以外の言語で受験するなら、用語は訳語ひとつで終わらせず、英語の原語と「この言葉が出たら、PMIはまず何をするか」までセットで覚えましょう。 ## 短くこまめに見るほうが記憶に残る理由 学習の研究で、昔から確かめられている原理が2つあります。 - **間隔効果**（spacing）：同じ時間をかけるなら、一度にまとめて見るより、何日かに分けて見るほうが長く記憶に残ります。 - **想起練習**（retrieval practice）：読み直すより、本を閉じて思い出してみるほうが、記憶がしっかり定着します。 通勤中の勉強は、この2つの原理と相性がいいです。毎日の行き帰りが自然と間隔を作ってくれますし、時間が短いので、読み直すより思い出すことに集中できます。[第6回](/ja/posts/pmp-error-log-method)の間違いノートで、1日後・7日後・21日後に見直すようにお伝えしたのも同じ原理です。 だから大事なのは、長さより頻度です。まとめて長くやって何日も休むより、毎日少しでもPMPの教材を開くほうがいいのです。 ## 私の通勤勉強：耳では音声、目では単語帳 通勤中には、2つのものを使いました。 **耳ではNotebookLMの音声**。テーマごとに作った韓国語のディープダイブを聞きました。1本が12分から24分ほどなので、通勤中に聞くのにちょうどいい長さでした。ノートブックの作り方と音声の設定方法は、[第7回](/ja/posts/pmp-gpt-notebooklm-study)にまとめています。 **目では単語帳**。音声が判断の流れをつかませてくれるとすれば、単語帳はその判断の手がかりになる用語を押さえさせてくれます。状況問題は、文中の単語ひとつで答えが分かれることもあります。リスクなのか課題なのか、検証なのか妥当性確認なのかによって、まずやる行動が変わるのです。 ## 英語以外の言語でPMPを受けるなら、用語はもっと大事です 私は韓国語で受験しました。翻訳版の試験では、問題と画面が受験する言語で表示され、各問題にあるExhibitボタンを押すと、問題と選択肢を英語で見られます。2つの言語が横に並んで表示される方式ではありません。 ここで引っかかるのが訳語です。同じ概念でも、講座、教材、問題集によって訳語が少しずつ違います。自分が覚えた訳語と試験画面の訳語が違うと、知っている概念でも見慣れないものに見えて、そのたびに英語の原文を開いて確認することになります。時間は限られているので、英語の原語と訳語をペアで覚えておくのがいちばんの近道です。 練習と本番の言語が違うこともあります。PMI Study Hallは英語でしか提供されていません。翻訳が必要なら、PMIはGoogle翻訳の拡張機能を案内しています。英語で練習して別の言語で受験するなら、用語を両方の言葉で知っておく必要があります。 新しい試験では、これがさらに重要になりました。2026年7月9日から実施されている新しい試験は、予測型が約40%、アジャイル・ハイブリッドが約60%です。プロダクト・バックログ、プロダクト・オーナー、スプリント・レビューといったアジャイルの用語が出てくる問題の比重が、それだけ大きくなったということです。変更点の詳細は[第5回：2026年PMP試験改定まとめ](/ja/posts/pmp-2026-exam-changes-pmbok-8)にまとめました。 ## 紛らわしい用語のペア4つ 用語は、ひとつずつ覚えるぶんには簡単です。難しいのは、似た2つの言葉が選択肢に並んで出てくるときです。次の4つのペアは、特に「まずやる行動」が分かれる組み合わせです。 ### 課題 vs リスク - **リスク**（risk）：まだ起きていない、不確実な事象や状態です。起きれば、プロジェクトの目標によくも悪くも影響します。リスク登録簿（risk register）に記録します。 - **課題**（issue）：すでに起きていて、いま影響を与えている問題です。課題ログ（issue log）に担当者と期限を決めて記録し、解決するまで追跡します。 特定済みのリスクが実際に起きたら、そこからは課題です。このときPMIがまずやるのは、計画しておいたリスク対応を実行することです。逆に、新しいリスクを見つけたなら、すぐに対応するより、まずリスク登録簿に記録して分析します。 ### 検証 vs 妥当性確認（verify vs validate） - **検証**（verify）：成果物が要求事項と仕様どおりに作られているかを、チームが確認することです。品質のコントロール（Control Quality）で行われ、通過した成果物が「検証済み成果物」になります。 - **妥当性確認**（validate）：顧客やスポンサーが、その成果物が自分たちのニーズを満たしているかを見て、正式に受け入れることです。スコープの妥当性確認（Validate Scope）がこれにあたります。 順番は、検証が先で妥当性確認があとです。アジャイルでは、スプリント・レビューでステークホルダーが成果物を直接見てフィードバックします。 韓国語の日常語では、どちらも「確認する」に近く聞こえるので、特に紛らわしいペアです。英語のペアで覚えておきましょう。verifyは「仕様どおりに作ったか」、validateは「顧客が求めるものを作ったか」です。第7回で紹介した音声「バグのないプロジェクトが受け入れを拒否された理由」も、タイトルからしてこの違いを思い出させます。仕様どおりに作って検証を通っても、顧客が受け入れるかどうかは別の問題です。 ### 変更要求 vs 欠陥修正 - **変更要求**（change request）：文書、成果物、ベースラインを変更するための正式な提案です。ステークホルダーが機能の追加を求めるような、合意したスコープを変える話なら、予測型ではまず影響を分析し、変更要求として提出して、変更管理の手続きで承認するかどうかを決めます。アジャイルでは、新しい要望としてプロダクト・バックログに入れ、プロダクト・オーナーが優先順位を決めます。 - **欠陥修正**（defect repair）：合意した要求事項を満たしていない成果物を、要求事項どおりに直すことです。要求事項はそのままで、成果物のほうを合わせます。 紛らわしいのは、どちらも正式な手続きと絡むことがあるからです。予測型のプロジェクトでは、欠陥修正も変更要求として提出し、承認を受けることがあります。だから、正式な手続きを通るかどうかより、「要求事項を変えるのか、要求事項に合わせるのか」でまず見分けるのが楽です。 ### プロダクト・オーナー vs プロジェクト・マネージャー - **プロダクト・オーナー**（PO）：何を、どの順番で作るかを決める人です。プロダクト・バックログを管理し、価値の大きい順に優先順位を付けます。顧客とビジネスの声をチームに届けます。 - **プロジェクト・マネージャー**（PM）：試験のアジャイル・ハイブリッドの状況では、PMはサーバント・リーダーです。チームが仕事を進められるよう障害を取り除き、ステークホルダーと調整し、チームをコーチします。バックログの優先順位を代わりに決めることはありません。 会社によっては「PM」がプロダクト・マネージャーを指すこともあり、2つの役割が混ざりやすいです。スプリント中にステークホルダーが新機能を求める問題なら、PMが自分で追加したり断ったりする選択肢は、たいてい罠です。まずプロダクト・オーナーにつなぎ、バックログで優先順位を決めてもらいます。 4つのペアを「この言葉が出たら、まず何をするか」に絞ると、こうなります。 | こんな状況が出たら | PMIがまずやること | |---|---| | 特定済みのリスクが発生した | 計画しておいたリスク対応を実行する | | 新しいリスクを見つけた | リスク登録簿に記録して分析する | | 仕様どおりに作ったのに、顧客が受け入れを拒否した | 受け入れ基準と要求事項を見直し、拒否の理由を確認する | | ステークホルダーが機能の追加を求めた（予測型） | 影響を分析し、変更要求として提出する | | 成果物が合意した要求事項と違う | 原因を分析し、要求事項に合わせて直す | | スプリント中に新しい要望が来た（アジャイル） | プロダクト・オーナーにバックログで優先順位を決めてもらう | ## 通勤中の5分単語ループ 単語帳は、こんなふうに使うのがおすすめです。1周5分なので、短い移動時間でも回せます。 1. **5分単位で区切ります**。最初から長く構えると、かえって始めにくくなります。 2. **意味を隠して用語だけを見ます**。英語の原語と訳語を一緒に思い出します。 3. **定義を一行で言ってみます**。声に出さなくてもかまいません。頭の中で一文言えれば十分です。 4. **その用語が出たら、PMIがまず何をするかまで言います**。定義だけ知っていて最初の行動を知らなければ、半分しかわかっていないということです。 5. **言えなかった単語には印を付けて、間違いノートに移します**。C（概念）タグを付けておけば、週間レビューで一緒に数えられます。 次のループは、印を付けた単語から始めます。昨日言えなかった単語を今日の最初の5分で思い出してみる。それこそが、間隔をあけた想起練習です。 単語帳が別になくても大丈夫です。間違いノートでCタグが付いたカードの用語を集めるだけでも、自分だけの単語帳になります。 ## 私がまとめた合格者の単語帳 下の「PMP通勤単語帳」は、私がPMPを勉強しながら実際に役立った用語を集めて整理したものです。一部はプレビューですぐに見られて、PDFの全体版はGumroadで$5.99で販売しています。上に書いた方法は単語帳がなくてもそのまま使えるので、必要なときだけ選んで使ってください。 ## おわりに 通勤中の勉強は、すごい意志の力が必要な方法ではありません。どうせ毎日過ぎていく時間に、PMPの教材をもう一度開いてみるだけです。私のように仕事のあと長く集中するのが難しい方は、勉強時間を増やすより、勉強を休む日を減らすことから始めてみてください。 間違いノートの書き方は[第6回](/ja/posts/pmp-error-log-method)に、GPTとNotebookLMの活用法は[第7回](/ja/posts/pmp-gpt-notebooklm-study)にあります。次の記事では、新しい試験のケーススタディ問題にどう備えればいいかをまとめます。 **次回**：[PMPケーススタディ問題の対策：2026年の新形式は、こう読んでこう解く](/ja/posts/pmp-case-study-questions) ## 参考資料 - [PMI公式：PMP資格の案内](https://www.pmi.org/certifications/project-management-pmp) - [PMI資格ハンドブック（Certification Handbook）（PDF）](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/generic-certification-handbook.pdf)：翻訳版の試験とExhibitボタンの案内 - [PMP試験内容概要（ECO）2026（PDF）](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf) - [PMI Study Hall Essentials](https://www.pmi.org/shop/p-/digital-product/pmp-pmi-study-hall-essentials-subscription/dp080) --- # GPTで概念を確認し直し、NotebookLMの音声で通勤復習：私のPMP AI勉強ルーティン > PMPの準備では、ChatGPTのプロジェクトで概念と間違いを点検し直し、ソース155件のNotebookLMノートブックで作った韓国語の音声を通勤中に聞きました。質問例と音声の設定方法もまとめています。 _Slug: pmp-gpt-notebooklm-study · 2026-09-19_ PMPの勉強にAIを使ったと言うと、AIが問題を代わりに解いてくれる姿を思い浮かべる人が多いかもしれません。私の場合は、ほぼ逆でした。GPTには正解ではなく自分の理解が合っているかを聞き、NotebookLM（現 Gemini Notebook）は耳で聞く復習教材にして、通勤中に聞いていました。 **3行まとめ**：ChatGPTのチャットは「PMP 시험공부」（PMP試験勉強）というプロジェクトひとつにまとめ、準備状況の診断、間違いノートの整理、Study Hallの結果の読み解きに使いました。NotebookLMにはソースを155件集めて12〜24分の韓国語の音声を作り、通勤中に聞きました。AIは間違ったことも自信満々に言うので、判断の最終的な基準はいつも試験内容概要（ECO）、PMBOKガイド、Study Hallの解説でした。 ## ひと目でわかる、私のAI勉強ループ [第1回](/ja/posts/pmp-pass-review-part-1)では、GPTとNotebookLMを何に使ったかを簡単に書きました。今回は実際の画面とあわせて、もう一歩踏み込んでみます。まずは全体の流れです。 > Study Hall → 間違えた問題 → GPTで説明・検証 → 間違いノート → NotebookLMにソースを追加 → 通勤中に音声 1. **Study Hall**で問題を解き、間違えた問題と勘で当たった問題を選び出します。 2. 迷った概念や選択肢は**GPT**に説明させ、自分の理解が合っているかを確かめます。 3. 確かめた内容を、原因タグと「〜なら、まず〜する」ルールの形で**間違いノート**に残します。書き方は[第6回](/ja/posts/pmp-error-log-method)にまとめました。 4. 整理したノートと参考資料を、**NotebookLM**のノートブックにソースとして入れます。 5. テーマごとに**音声解説**を作り、通勤中に聞きます。 GPTは理解を点検する道具で、NotebookLMは移動時間を復習時間に変えてくれる道具でした。 ## ChatGPT：「PMP 시험공부」プロジェクトひとつにまとめる ChatGPTでは、PMPのチャットをばらばらにせず、「PMP 시험공부」（PMP試験勉強）というプロジェクトひとつにまとめました。プロジェクトにしておくと、PMPの話だけが一か所に集まるので、過去のチャットを探し直すのも簡単です。 ChatGPTのプロジェクト「PMP 시험공부」のチャット一覧。準備状況、間違いノートの整理、準備の診断、Percentile Rank、初めてのStudy Hall分析といった韓国語タイトルのチャットが並び、一部の項目にはモザイクがかかっている *ChatGPTのプロジェクト「PMP 시험공부」のチャット一覧。個人的な項目3つ（チャット2つと別のプロジェクト1つ）にはモザイクをかけています。* チャットのタイトルを見るだけで、何に使ったかがわかります。 | チャット（韓国語のタイトル） | 用途 | |---|---| | PMP 시험 준비 상황（PMP試験の準備状況） | いまどこまで来ているかの点検 | | PMP 시험 준비 진단（PMP試験の準備診断） | 準備状況の診断（「PMPマインドセットは暗記すべき？」） | | 오답노트 (정리)（間違いノートの整理） | 間違えた問題の原因の分類とルールの整理 | | 첫 Study Hall 분석（初めてのStudy Hall分析） | 初めてのStudy Hallの結果の分析 | | Percentile Rank 해석（Percentile Rankの読み方） | Study Hallが示すPercentile Rankの解釈 | Study HallのPercentile Rankは、同じ商品を使っているほかの受験者と比べた自分の位置です。点数を見るたびに不安になっていたので、この数字が正確に何を意味するのかも別に聞いてみました。 「PMP 시험 준비 진단」（準備診断）のチャットには、マインドセットを暗記すべきか悩んだ跡がそのまま残っています。結論は第1回に書いたとおりです。マインドセットは無条件に当てはめる暗記の公式ではなく、倫理・法規・安全・緊急のリスクといった例外を知ったうえで使う判断の順番でした。 GPTの使い方も、第1回に書いたとおりです。正解を代わりに選ばせるのではなく、自分の理解を点検するために使いました。Study Hallの問題を貼り付けて、AIが選んだ答えだけを確認するやり方は、第1回と[第2回](/ja/posts/pmp-pass-review-part-2)でも書いたように、おすすめしません。 ## GPTにはこう聞いてみてください 以下の質問は、私のチャットをそのまま写したものではありません。PMPの勉強にGPTを使うならこう聞くのがおすすめ、という形で新しく整理しました。第1回で紹介した質問例と重ならないよう、4つの用途に分けています。 ### 1. 概念はまず自分の言葉で説明して、穴だけ指摘してもらいましょう 説明を丸ごと受け取ると、読んで終わりになります。自分が先に説明して間違っている部分だけを指摘してもらえば、その穴がそのまま間違いノートのC（概念）タグになります。 ```text PMPの「スコープの妥当性確認（Validate Scope）」を自分の言葉で説明してみるね。 「品質のコントロールで検証された成果物を、顧客やスポンサーが正式に受け入れること。」 間違っているところや抜けているところだけ指摘して。説明を最初から書き直さないで。 ``` ### 2. 正解と2番手の選択肢を比べてもらいましょう PMPで難しいのは、正解ともっともらしい2番手との違いです。問題を丸ごと貼り付けるより、状況を一行にまとめて、迷った2つの選択肢だけを並べて聞いてみてください。要約しているあいだに、もう半分は復習できています。 ```text 状況：アジャイルチームの開発者2人が、技術的な進め方で衝突を繰り返している。PMがまずやることは？ 候補1：機能部門のマネージャーに報告し、判断を仰ぐ。 候補2：2人と話す場を設け、合意点を見つけられるよう支援する。 どちらも取りうる行動だ。問題がFIRSTを問うなら、PMIの視点でどちらが先か、 そしてもう一方はどんな条件なら正解になるのかを説明して。 ``` ### 3. 自分のルールが崩れる反例を作ってもらいましょう ルールは、例外を知ってこそ強くなります。「対立なら、まず対話」を信じすぎると、すぐに対処すべき状況でも対話を選んでしまいます。 ```text 私の間違いノートのルール：「チームの対立なら、まず当事者同士の対話を支援する。」 このルールをそのまま当てはめると不正解になる状況を3つ作って。 倫理違反や安全の問題のように、すぐに対処すべきケースも入れて。 ``` ### 4. 自分のルールでクイズを出してもらいましょう 第6回のテンプレートにある「試験前夜に読む：自分のルール10」を、そのまま入れればOKです。ポイントは、正解より先に自分の根拠を言わせることです。 ```text 以下は私の間違いノートのルール10個だ。ルールごとに状況問題を1問ずつ作って。 選択肢は4つで、どれももっともらしく。私が答えたらすぐに採点せず、 まずなぜその答えを選んだのかを聞いてから採点して。 ``` AIは間違った内容も自信満々に話します。PMBOKは版ごとに構成が違うため（第7版は原則12個、第8版は6個）、基準が混ざった説明が出てくることもあります。GPTの説明がStudy Hallの解説と食い違ったら、Study Hallの解説と[ECO](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf)、[PMBOKガイド](https://www.pmi.org/standards/pmbok)を基準に確認し直してください。 ## NotebookLM：ソース155件で上限に達したノートブック まず名前を整理しておきます。NotebookLMは2026年7月16日に、Gemini Notebookへと名前が変わりました。同じ製品です。私が勉強していたころはNotebookLMだったので、この記事ではNotebookLMと呼びます。下のスクリーンショットのいちばん下にある注意書きには、すでに新しい名前が表示されています。 ノートブックの名前は「Agile Mindset and Key Concepts for the PMP Exam」です。PMIに入会してStudy Hallを購入した1週間後、6月8日に作りました。資料を入れ続けた結果、いまはソースが155件になり、ソースの上限に達したという案内が表示されています。 NotebookLMのノートブック「Agile Mindset and Key Concepts for the PMP Exam」の画面。ソース155件と2026. 6. 8.の日付が表示され、左にはRedditやYouTubeなどのソース一覧とソース上限の案内、右のStudioパネルには韓国語の音声の一覧が見える *2026年6月8日に作ったNotebookLMのノートブック。左上にソースの上限に達したという案内、右のStudioパネルに韓国語の音声の一覧が見えます。いちばん下の注意書きの名前は、すでにGemini Notebookです。* ソースには、自分でまとめたノートのほかに、こんな資料が入っています。 - Redditのr/PMPにある試験対策のスレッド - YouTube動画「ALL the A.I. in the New PMBOK 8th Edition」 - アジャイルの問題と予測型の問題の見分け方を扱ったガイド ソースが増えるほど、AIがどの資料を根拠に話しているのかを確かめにくくなります。Redditの投稿やYouTube動画から出てきた話は参考程度に聞き、判断の基準は公式資料とStudy Hallの解説に置くのが安全です。 ## 通勤中に聞いた韓国語のディープダイブ このノートブックの核心は、Studioパネルの音声解説（Audio Overview）でした。入れておいたソースをもとに、AIがポッドキャストのように解説してくれる機能で、デフォルトの形式であるディープダイブ（Deep Dive）では、2人のホストが対話するように説明します。私はテーマごとに韓国語のディープダイブを作り、通勤中に聞いていました。 Studioパネルの音声解説の一覧。韓国語のディープダイブのタイトルと、17:57や12:27といった長さが並んでいる *Studioパネルの音声の一覧。ほとんどが韓国語のディープダイブで、長さは12分27秒から23分34秒までです。* | 音声のタイトル（韓国語） | おおよその意味 | 長さ | |---|---|---| | 실무 본능이 PMP 사람 영역에서 오답인 이유 | 実務の勘がPMPのPeople領域で不正解になる理由 | 17:57 | | PMP 규정 준수 문제 정답 패턴 정리 | PMPのコンプライアンス問題、正解パターンのまとめ | 12:27 | | 프로젝트의 명확한 울타리를 치는 범위 관리 | プロジェクトに明確な柵を立てるスコープ・マネジメント | 21:57 | | PMP 일정 관리 정답은 크리티컬 패스에 있다 | PMPのスケジュール・マネジメント、正解はクリティカル・パスにある | 23:18 | | PMP 리스크와 조달 정답 판단 공식 | PMPのリスクと調達、正解を見抜く公式 | 14:44 | | 경력직 PM도 틀리는 PMP 정답 논리 | ベテランPMでも間違えるPMPの正解ロジック | 20:32 | | PMP 애자일 하이브리드 정답 마인드셋 공식 | PMPのアジャイル・ハイブリッド、正解に導くマインドセットの公式 | 20:30 | | 현업 PM도 틀리는 PMP 변경관리 함정 | 現役PMでもはまるPMPの変更管理の罠 | 23:34 | | 버그 없는 프로젝트가 인수를 거절당한 이유 | バグのないプロジェクトが受け入れを拒否された理由 | 23:05 | タイトルには共通点があります。「正解パターン」「公式」「罠」といった言葉からわかるように、ほとんどが、実務では正しいのに試験では間違えやすいポイントを掘り下げています。用語の定義は目で読んだほうが早く、「なぜこれが先なのか」といった判断のロジックは、話として聞くと頭に入りやすいです。 PeopleがBelow Targetだった私にとって、「実務の勘がPMPのPeople領域で不正解になる理由」はタイトルからして耳が痛いです。「バグのないプロジェクトが受け入れを拒否された理由」は、タイトルを見ただけで検証（verify）と妥当性確認（validate）の違いが頭に浮かびます。この用語のペアは[第8回](/ja/posts/pmp-commute-study-vocabulary)で別にまとめました。 ## 音声解説の作り方 Googleのヘルプをもとにまとめると、次のとおりです。 1. ノートブックを開いて、ソースを入れます。 2. Studioパネルで音声解説を選びます。 3. カスタマイズで形式・言語・長さを選び、何に焦点を当てるかをプロンプトに書きます。 | 設定 | 選べるもの | 知っておきたいこと | |---|---|---| | 形式 | ディープダイブ（Deep Dive、デフォルト）、要約（Brief）、批評（Critique）、討論（Debate） | ディープダイブは2人のホストの対話、要約は1人が2分以内で要点だけを話す | | 言語 | 80以上 | 韓国語も可 | | 長さ | 短め、デフォルト、長め | 「長め」は英語のみ | | フォーカスのプロンプト | 自由入力 | 扱うテーマや説明のレベルを指定 | デフォルトの形式の名前は、私の画面では「딥 다이브」（ディープダイブ）、韓国語のヘルプでは「심층 분석」（詳細な分析）と表記が違いますが、同じ機能です。ホストの対話に割り込んで質問できるインタラクティブモードもありますが、いまは英語でしか使えません。 フォーカスのプロンプトは、こんなふうに書いてみてください。1本にテーマをひとつだけ盛り込むのがポイントです。私のリストも、スコープ、スケジュール、リスク・調達、変更管理、アジャイル・ハイブリッドのように、テーマ別に分かれています。 ```text PMP試験の状況問題に備える受験者向けの音声だよ。 「変更管理」で、実務の習慣とPMIの正解が分かれるポイントを中心に、 「この状況なら、まず何をするか」を例とあわせて説明して。 予測型とアジャイルで、まずやる行動がどう変わるかも比べて。 ``` 音声解説はAIが作った音声なので、間違った内容が混ざることがあります。Googleのヘルプにもそう書かれていますし、私のノートブックの画面の下にも「Gemini Notebook은 실수를 할 수 있으니 다시 한번 확인하세요.」（Gemini Notebookは間違えることがあるので、もう一度確認してください）という文言が表示されています。聞いていて首をかしげたくなる説明はメモしておき、公式資料で確認してください。 ## おわりに AIが勉強を代わりにしてくれたわけではありません。そのかわり、勉強できる時間と場所を増やしてくれました。GPTでは自分の理解を点検し、移動中は音声で同じテーマをもう一度聞きました。 次の記事では、その通勤時間をどう使ったのか、そして翻訳版の試験（私の場合は韓国語）を受けるとき、なぜ用語を別に押さえておくべきなのかをまとめました。私がまとめた単語帳も紹介します。 **次回**：[通勤時間のPMP勉強法：短く濃く、こまめに見る（＋合格者の単語帳）](/ja/posts/pmp-commute-study-vocabulary) **前回**：[PMP間違いノートの書き方：間違えた問題を「判断ルール」に変える6ステップ](/ja/posts/pmp-error-log-method) ## 参考資料 - [Googleヘルプ：NotebookLMの音声解説を作成する](https://support.google.com/notebooklm/answer/16212820?hl=ja) - [PMP試験内容概要（ECO）2026（PDF）](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf) - [PMI：PMBOKガイド](https://www.pmi.org/standards/pmbok) - [PMI Study Hall Essentials](https://www.pmi.org/shop/p-/digital-product/pmp-pmi-study-hall-essentials-subscription/dp080) --- # PMP間違いノートの書き方：間違えた問題を「判断ルール」に変える6ステップ（無料Wordテンプレート付き） > PMPの間違いノートは、問題を写すノートではなく、判断ルールを積み上げるノートです。勘で当たった問題まで記録し、C・R・M・S・A・Tのタグで原因を分けてルールに変える6ステップと、無料のWordテンプレート。 _Slug: pmp-error-log-method · 2026-09-17_ PMPの準備に費やした7週間で、私がいちばん長く向き合っていたのは新しい問題ではありませんでした。すでに間違えた問題です。Study Hallの模擬試験は66%と65%。その点数で試験会場に入り、PASSをもらって出てきましたが、振り返ると、あの点数で合格できたのは間違いノートによるところが大きかったと思います。 **3行まとめ**：PMPの間違いノートは、正解を覚えるためのノートではなく、「〜なら、まず〜する」という判断ルールを積み上げるノートです。間違えた問題と勘で当たった問題をすべて記録し、原因をC・R・M・S・A・Tの6つのタグに分けて、1日後・7日後・21日後に見直します。私が使っていたやり方は9ページのWordテンプレートにまとめて、無料で配布しています。 テンプレートは[下](#template)から無料で受け取れます。日本語・英語・韓国語・スペイン語の4つの言語版があります。 ## PMPの間違いノートは「判断」を直すノートです PMPの問題の多くは、知識をそのまま問うものではありません。プロジェクトで起こりそうな状況をひとつ示して、プロジェクト・マネージャー（PM）がいま、まず何をすべきかを選ばせます。 厄介なのは、選択肢のほとんどが「間違った行動」ではないことです。上司に報告するのも、会議を開くのも、計画を見直すのも、実務ではどれもやることです。正解と不正解を分けるのは、知識よりも**順番と優先順位**です。 だから、問題と正解を書き写す普通の間違いノートは、PMPではあまり効きません。[第1回](/ja/posts/pmp-pass-review-part-1)にも書きましたが、正解の文章を覚えたら、言葉が少し変わっただけでまた間違えました。残すべきなのは問題ではなく、「次に似た状況が来たら、自分はまず何をするか」というルールです。 私のStudy Hallのフル模擬試験（Full Mock）の点数は66%と65%、全体の平均は約62%でした。高得点の合格体験記を読むたびに不安になりましたが、点数よりも私が信じていたのは、同じ理由で間違える問題が減ってきているというサインでした。そのサインを目で確かめさせてくれたのが、間違いノートです。 ## 間違えた問題を判断ルールに変える6ステップ やり方は、テンプレートの1ページ目に書いた「使い方」の6行そのままです。間違いカード1枚には、状況の要約、自分の答えと正解、正解がいちばん適切な理由、はまった罠、原因タグ、次のためのルール、復習の欄があります。 PMP 間違いノートのWordテンプレート2ページ分のプレビュー。左は使い方の6ステップとC・R・M・S・A・Tの原因タグ表、右は記入例のカードと「いいルール、だめなルール」の表 *間違いノートのテンプレート1〜2ページ。左が使い方と原因タグ、右が記入例と「いいルール、だめなルール」の表です。* ### ステップ1：間違えた問題と「勘で当たった」問題をすべて記録する 間違えた問題だけを記録すると、半分を見落とします。2択まで絞って勘で選んだものが当たったなら、それは運がよかっただけの不正解です。本番でその運がまた来る保証はありません。 そこで、カードごとに「確信度」の欄を設けて、確実・あいまい・勘のどれかにチェックします。正解しても、あいまいだったり勘だったりしたら記録します。逆に、確実にわかって正解した問題まで書く必要はありません。その時間で、間違えた問題をもう一度見直すほうが得策です。 ### ステップ2：問題文は写さず、状況を一行にまとめる 問題を丸ごと書き写すと時間がかかるうえ、結局は文章を覚えることになります。代わりに、誰が、どんな状況で、何を問われているのかだけを一行に縮めます。 > アジャイルチームの開発者2人が技術的な進め方で衝突を繰り返し、スタンドアップの空気まで悪化。PMがまずやることは？ 一行に縮めるには核心を見つけなければならないので、要約すること自体が復習になります。このとき、ドメイン（People・Process・Business Environment）とアプローチ（予測型・アジャイル・ハイブリッド）にもチェックを入れておきましょう。数週間分たまると、「自分はアジャイルの状況のPeopleの問題に弱い」といったパターンが見えてきます。 新しい試験ではBusiness Environmentの比重が8%から26%に大きくなったので、ドメインの欄も読み飛ばさないでください。変更点は[第5回：2026年PMP試験改定まとめ](/ja/posts/pmp-2026-exam-changes-pmbok-8)に整理しました。 ### ステップ3：自分の答えと正解、そして正解が「いちばん」適切な理由を書く 自分の答えと正解を並べて書いたら、いちばん大事な欄を埋めます。正解がなぜ正しいのかではなく、なぜ**いちばん**適切なのかです。 PMPでは、自分が選んだ答えもたいていはもっともらしい行動です。だから「なぜ自分の答えではなく、この答えが先なのか」を、PMIの視点で1〜2文で説明できなければなりません。説明が出てこないなら、まだ理解できていないということです。 そのすぐ下の欄には、自分の答えが違った理由、つまりはまった罠を書きます。「エスカレーションが早すぎた」「問題文のFIRSTを見落とした」のように短く書けば十分です。 ### ステップ4：間違えた原因にC・R・M・S・A・Tのタグを付ける 原因を分けておくと、点数がただの成績表から処方箋に変わります。テンプレートには6つのタグを入れました。 | タグ | こんなとき | こう直す | |---|---|---| | C 概念 | 用語やプロセスを知らなかった | 自分の言葉で一行に定義し、例をひとつ添える | | R 読み違い | FIRST・NEXT・BEST・EXCEPTなどの条件を見落とした | 問題の最後の一文から読む | | M マインドセット | 状況は理解したが、PMIの優先順位とずれた | 「PMIならまず何をする？」と自問する | | S 順序 | 行動は正しいが順番が違った（評価 → 計画 → 実行） | 「まずやること」と「次にやること」を分ける | | A アプローチ | アジャイル・予測型・ハイブリッドの文脈を取り違えた | スプリント、バックログ、変更管理などの手がかりに印を付ける | | T 時間 | 時間が足りず勘で答えた | 1問あたりの平均時間を記録する | タグはひとつに絞る必要はありません。あとで紹介する記入例にも、MとRの両方が付いています。 第1回と[第2回](/ja/posts/pmp-pass-review-part-2)に書いた自分のミスのリストを見直すと、ほとんどがこの6つのどれかに入ります。すぐにスポンサーに上げてしまった問題はM、FIRSTとNEXTを区別しなかった問題はR、変更の影響を分析する前に実行した問題はS、予測型とアジャイルの状況を取り違えた問題はAです。試験当日、最初の60問に約80分かかったのは、Tの警告でした。 ### ステップ5：「〜なら、まず〜する」というルールにする この一行が、間違いノートの成果物です。ほかの欄はすべて、この一文を書くための材料です。 ルールは、試験中に3秒で思い出せなければ意味がありません。そのために守ることは2つだけです。 - 状況は具体的に書く。「対立」ではなく「チームメンバー同士の対立」のように。 - まずやる行動はひとつだけ書く。 「〜なら、まず〜する」という型に当てはめて書けば、この2つは自然と守られます。 ### ステップ6：1日後・7日後・21日後に解き直し、週に一度タグを数える 書いたきり見返さなければ、間違いノートはすぐに引き出しの奥で眠るノートになります。カードには1日後・7日後・21日後の復習欄があります。翌日、1週間後、3週間後に状況の要約だけを見てもう一度判断し、「解き直し」の欄に「正解」か「また間違えた」をチェックします。一度にまとめて見るより、間隔をあけて何度も見返すほうが記憶に長く残ります。 そして週に一度、その週に付けたタグを数えます。テンプレートの週間レビュー表には、解いた数、間違い、正答率、C・R・M・S・A・Tそれぞれの数と「来週の重点」の欄があります。いちばん多かったタグが来週の宿題です。Mが多ければマインドセットを整理し直し、Rが多ければ問題の最後の一文から読む練習を、Tが多ければ時間を計って解く練習をする、という具合です。 試験が近づいたら、「つい破ってしまうルール Top 3」と「試験前夜に読む：自分のルール10」を埋めます。第2回に書いたとおり、私は試験の2日前から、新しい問題より間違いノートを繰り返し見ていました。そのときに見直すのはカード全部ではなく、こうして絞り込んだ短いリストです。 ## 記入例：チームの対立で、まず「報告」を選んでしまったら テンプレートの2ページ目に載せた記入例を、1欄ずつ見ていきましょう。実際の試験問題ではなく、よく出るパターンをもとに作った例です。 | 欄 | 記入内容 | |---|---| | 出典・ドメイン・アプローチ | 模擬試験・People・アジャイル | | 状況を一行で | アジャイルチームの開発者2人が、技術的な進め方をめぐって何度も衝突している。デイリースタンドアップの空気まで悪くなった。PMがまずすべきことは？ | | 自分の答え | B. 機能部門のマネージャーに報告し、判断を仰ぐ | | 正解 | C. 2人と話す場を設け、それぞれの根拠を聞き、合意点を見つけられるよう支援する | | 確信度 | あいまい | | 正解が「いちばん」適切な理由 | 対立はまず当事者同士で、協働（問題解決）によって解決する。自己組織化チームのPMは代わりに決める人ではなく、対話を促すサーバント・リーダーだ。 | | 自分の答えが違った理由（はまった罠） | 報告やエスカレーションは、チーム内で解決できないときの最後の手段。「まず（FIRST）」という条件を見落とした。 | | 原因 | M マインドセット、R 読み違い | | 次のためのルール | チームの対立なら、まず当事者同士の対話を支援する。エスカレーションは最後。 | | 復習 | 1日後 完了 | Bに惹かれるのは、実務ではそれが責任ある行動に見えるからです。チームメンバー2人がぶつかったら、上に知らせて判断を仰ぐのが早くて安全に思えますよね。でもPMPでは、PMはチームが自分たちで問題を解決できるよう支援する人です。チーム内で解決できることを先に上へ上げてしまうと、不正解になります。 とはいえ、エスカレーションがいつも不正解というわけではありません。話し合いで解決しなければ、そのあとで上げればいいのです。だからルールの最後に「エスカレーションは最後」と付けました。このひと言が、「エスカレーションは無条件で不正解」と間違って覚えるのを防いでくれます。 このパターンは、第1回の私のミスのリストにも入っていました。結果レポートでPeopleがBelow Targetだったのを見ると、最後まで宿題として残った部分だったのだと思います。 ## いいルール、だめなルール 最初にルールを書くと、決意表明のようになりがちです。「対立問題に気をつける」といった具合です。間違ってはいませんが、試験会場ではこの一文は何も教えてくれません。何に気をつけるのか、だからまず何をするのかが書かれていないからです。 | だめなルール | いいルール | |---|---| | 対立問題に気をつける | チームの対立なら、まず当事者同士の対話を支援する。 | | 変更管理を見直す | 予測型でスコープ変更の要望が来たら、まず影響を分析してから変更要求を出す。 | | アジャイルと混同しない | スプリント中に新しい要望が来たら、まずプロダクトオーナーにバックログで優先順位を決めてもらう。 | | リスクは丁寧に | 特定済みのリスクが発生したら、まず計画どおりのリスク対応を実行する。 | いいルールには3つの共通点があります。状況が具体的で、まずやる行動がひとつで、3秒で思い出せるほど短いことです。 テンプレートの最後のページには、試験によく出る判断パターンを一行ずつ12個書いておきました。いくつか抜き出すと、こんな感じです。 - 問題が起きたら、まず状況を把握して分析する。すぐに報告したり動いたりしない。 - 予測型では、スコープ・スケジュール・コストの変更は統合変更管理を通す。 - アジャイルでは、バックログの優先順位はプロダクトオーナーが決める。 - 品質は検査より予防。 - メンバーの成果の問題は、1対1で原因から聞く。 暗記するためのリストではありません。自分の間違いノートのルールと並べて、自分のルールがこのうちどの行の具体版なのかを確かめるためのものです。第1回に書いたとおり、倫理、法規、安全、緊急のリスクのように、すぐに対処すべき例外もあるからです。 ## ChatGPTに分けておいた、間違いノート用のチャット 間違いノートを整理するときは、ChatGPTも一緒に使いました。「PMP 시험공부」（PMP試験勉強）というプロジェクトの中に、「오답노트 (정리)」（間違いノートの整理）というチャットを別に作っていました。 ChatGPTのプロジェクト「PMP 시험공부」のチャット一覧。準備状況、間違いノートの整理、準備の診断、Percentile Rank、初めてのStudy Hall分析といった韓国語タイトルのチャットが並び、一部の項目にはモザイクがかかっている *ChatGPTのプロジェクト「PMP 시험공부」のチャット一覧。個人的な項目3つにはモザイクをかけています。* GPTには間違えた理由を分類させ、自分の判断の過程を説明したうえで、抜けている前提を指摘してもらいました。ただし、最後のルールの一文だけは自分の言葉で書きました。自分の言葉で書いた文でないと、試験会場で思い浮かばないからです。 GPTに何を、どう聞けばいいかは、[第7回](/ja/posts/pmp-gpt-notebooklm-study)で質問例とあわせてまとめました。 ## 無料のPMP 間違いノート テンプレート（Word） この記事で説明したやり方を、そのままWordファイルにしました。全9ページです。 - 1ページ：使い方の6ステップと原因タグ（C・R・M・S・A・T） - 2ページ：記入例、いいルールとだめなルール - 3〜7ページ：空欄の間違いカード10枚 - 8ページ：週間レビュー表、「つい破ってしまうルール Top 3」、「試験前夜に読む：自分のルール10」 - 9ページ：PMPマインドセットの一行ルール12個 日本語・英語・韓国語・スペイン語版があり、申し込むときにファイルの言語を選べます。下の欄にメールアドレスを入力し、ニュースレターの購読に同意すると、ダウンロードリンクをメールでお送りします。 ## おわりに 間違いノートを書くのに時間がかかるのは確かです。それでも私にとっては、新しい問題をもっと解くより、間違えた問題ひとつを一行のルールに変えるほうが、試験会場で役に立ちました。同じ問題は二度と出ませんが、同じ判断は何度でも出てくるからです。 新しい試験のケーススタディ問題も、同じカードに記録すれば大丈夫です。ケーススタディの対策は[第9回](/ja/posts/pmp-case-study-questions)で別に取り上げます。 次の記事では、この間違いノートをGPTで点検し、NotebookLM（現 Gemini Notebook）の音声で通勤中に復習した方法をまとめました。 **次回**：[GPTで概念を確認し直し、NotebookLMの音声で通勤復習：私のPMP AI勉強ルーティン](/ja/posts/pmp-gpt-notebooklm-study) ## 参考資料 - [PMI公式：PMP資格の案内](https://www.pmi.org/certifications/project-management-pmp) - [PMP試験内容概要（ECO）2026（PDF）](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf) - [PMI Study Hall Essentials](https://www.pmi.org/shop/p-/digital-product/pmp-pmi-study-hall-essentials-subscription/dp080) --- # 2026年PMP試験改定まとめ：変わったこと、そしてPMBOK第7版 vs 第8版 > 2026年7月9日に変わったPMP試験を、改定前と表で比較しました。問題数・試験時間・休憩、ドメインの比重、受験資格の変更、PMBOK第7版と第8版の違い、PMIのAI標準までまとめています。 _Slug: pmp-2026-exam-changes-pmbok-8 · 2026-09-15_ 昨日（9月14日）、PMIから会員向けのメールが1通届きました。件名は「Your member access: PMI's AI Standard」。プロジェクトマネジメント分野のAI標準を、会員は無料で読めるという案内でした。 PMIの会員向けメール。「Bring structure to AI adoption」という見出しと『The Standard for Artificial Intelligence in Portfolio, Program and Project Management』の表紙、8つの原則とANSI承認のAI標準という紹介文 *2026年9月14日に届いたPMIの会員向けメール。AI標準の8つの原則と、「ANSIの承認を受けた、プロジェクト分野で初の、そして唯一のAI標準」という紹介が見えます。* このメールは、最近のPMIが向かっている方向をよく表しています。AIをどう扱うかの原則を定め、プロジェクトを「価値」で判断し、サステナビリティにまで目を配る方向です。PMP試験も、2026年7月9日からこの方向に変わりました。 私は改定の6日前、7月3日に改定前の試験で合格しました。ですから、この記事は新試験の受験記ではありません。その代わりに、PMIの公式文書、つまり2026年版の試験内容概要（ECO）、資格ハンドブック、PMBOKガイドの案内ページをもとに、何が変わったのか、勉強の仕方はどう変えるべきかをまとめました。 **3行まとめ**：2026年7月9日から、PMPは180問（採点対象170問＋採点対象外10問）・240分の試験になり、冒頭にケーススタディのセクションが置かれました。最大の変化は、Business Environmentの比重が8%から26%へと3倍以上に増えたことです。PMBOKも第8版で原則6つ、パフォーマンス領域7つに再編されましたが、試験は特定の1冊を基準に出題されるわけではありません。 ## ひと目でわかる比較：改定前 vs 改定後 | 項目 | 改定前（私が受けた試験） | 改定後（2026年7月9日〜） | |---|---|---| | 問題数 | 180問（採点対象175問＋プレテスト5問） | 180問（採点対象170問＋採点対象外10問） | | 試験時間 | 230分 | 240分 | | 休憩 | 10分×2回（60問目と120問目のあと） | 10分×2回（ケーススタディのセクションのあとと、独立した問題の半ばあたり） | | 新しい問題形式 | — | ケース・シナリオ形式の問題、グラフィックベースの問題 | | ドメインの比重 | People（人）42%・Process（プロセス）50%・Business Environment（ビジネス環境）8% | People 33%・Process 41%・Business Environment 26% | | タスク数 | 35 | 26（People 8・Process 10・Business Environment 8） | | アプローチ | 予測型 約50%・アジャイル／ハイブリッド 約50% | 予測型 約40%・アジャイル／ハイブリッド 約60% | | 経験が認められる期間 | 直近8年 | 直近10年 | | 学歴別のルート | 高卒60か月、学士36か月など | 短大など（EQFレベル5）の48か月ルートを新設 | | 35時間の研修 | ライブ講座の機関に制限なし | 2026年12月1日から、ライブ講座はATP・中国のREP・認定を受けた高等教育課程のものだけを認定 | | 本人確認 | — | 支払い前に、Personaで自撮り写真と政府発行の身分証明書を確認 | | 受験料（韓国、PMI会員） | $405（私の6月の領収書） | $405（2026年10月3日時点のPMIストア） | 問題数は180問のままです。その代わり、採点対象の問題が175問から170問に減り、採点されない問題が5問から10問に増えました。試験時間は10分延びて240分になりました。 ちなみに、私のPearson VUEの予約時間は270分でした。試験の230分に、チュートリアル、同意手続き、アンケートの時間が加わった数字です。予約確認メールの話は[合格体験記の第2部](/ja/posts/pmp-pass-review-part-2)に書いています。 新しく登場したケース・シナリオ形式の問題とグラフィックベースの問題は、テストセンター試験とオンライン試験の両方で出題されます。一方、マッチング、ホットスポット、プルダウンといった形式は、テストセンターでしか出ません。 ## 勉強の仕方が変わる6つのポイント 表の数字が実際の勉強にとってどんな意味を持つのか、一つずつ見ていきます。 ### 1. Business Environmentが8%から26%に 最大の変化です。私が受けた試験では、Business Environmentは全体の8%しかない小さな領域でした。それが今では、4問に1問の割合です。 私の結果レポートでは、Business EnvironmentはAbove Targetでした。ただ、当時は比重が小さかったので、全体の結果に与える重みも小さかったのです。今準備している方は、この領域を「おまけ」扱いしてはいけません。タスク数も、Peopleと同じ8つです。 ### 2. アジャイル・ハイブリッドが60%に 予測型とアジャイル・ハイブリッドの比率は、約50:50から40:60に変わりました。ハイブリッドの状況が増えるほど、「この部分は予測型、この部分はアジャイル」と見分けることが重要になります。 [合格体験記の第2部](/ja/posts/pmp-pass-review-part-2)に書いた私のくり返しのミスの一つが、予測型とアジャイルの状況を混同することでした。新試験ではこの区別がより頻繁に問われると考えて、準備しておくべきです。 ### 3. 「価値にもとづくデリバリー」がタスクに加わった Processドメインに「Help ensure value-based delivery」というタスクが新しくできました。スケジュールと予算を守ったかどうかだけでなく、その結果が価値を生んだかどうかまで見る、という意味に読めます。PMBOK第8版がプロジェクトを「価値を生み出すためのもの」と定義しているのと同じ流れです。 ### 4. サステナビリティは4つのタスクの中に サステナビリティ（sustainability）は、独立したタスクではありません。計画、品質、コンプライアンス、リスクという4つのタスクのイネーブラー（enabler：タスクを具体的に示す活動例）に組み込まれました。別の単元として暗記するより、計画やリスクを考えるときに一緒に検討する視点として身につけておいてください。 ### 5. AIは領域ではなく、シナリオの中に AIだけを扱うドメインやタスクはありません。AIとサステナビリティは、試験範囲を決める職務分析に反映され、試験ではAIがシナリオの文脈の中で登場します。「AIの領域が新しくできた」という話は事実ではありません。 ### 6. ケーススタディが試験の冒頭に 新試験は、ケーススタディのセクションから始まります。1つのシナリオに複数の問題が付いていて、このセクションが終わると1回目の休憩です。休憩を始めると、前のセクションには戻れません。読む順番と時間配分は、[第9回：ケーススタディ問題の対策](/ja/posts/pmp-case-study-questions)で別に扱います。 ## 受験資格も変わった 変わったのは試験だけではありません。申請の条件も一緒に変わりました。 - **経験が認められる期間**：直近8年から直近10年に延びました。私が6月に申請したときは、8年の基準でした。 - **48か月ルートの新設**：短大などEQFレベル5の学歴なら、48か月の経験で受験できます。学士の36か月、高卒の60か月、GAC認定の学位の24か月は変わりません。 - **35時間の研修**：2026年12月1日から、ライブ講座は、PMI認定トレーニング・パートナー（ATP）、中国のREP、認定を受けた高等教育課程で受けたものだけが認められます。自分のペースで進める講座は機関を問わず認められ、書籍や模擬試験だけでは満たせません。有効なCAPMがあれば、35時間は免除されます。 - **本人確認**：申請の段階に「強化された確認（enhanced verification）」が加わり、支払いの前にPersonaで自撮り写真と政府発行の身分証明書を確認します。 経歴欄の書き方や、Auditに当たったら何を提出すればいいのかは、[第4回：経歴の書き方とAudit](/ja/posts/pmp-experience-application-audit)にまとめました。 ## PMBOK第7版 vs 第8版 PMPの話をするなら、PMBOKは外せませんよね。第8版は2025年11月に出ました（発売の発表は11月13日）。408ページあり、PMIは4万8,000を超えるデータポイントを反映したと紹介しています。PMI会員は、PDFを無料で入手できます。 | 区分 | PMBOK第7版 | PMBOK第8版 | |---|---|---| | 刊行 | 2021年8月1日 | 2025年11月（11月13日に発売を発表） | | 原則 | 12：スチュワードシップ、チーム、ステークホルダー、価値、システム思考、リーダーシップ、テーラリング、品質、複雑さ、リスク、適応性と回復力、変革 | 6：Holistic view（全体を俯瞰する視点）、Focus on value（価値に焦点を当てる）、Embed quality（品質を組み込む）、Accountable leadership（責任あるリーダーシップ）、Integrate sustainability（サステナビリティの統合）、Empowered culture（権限を与える文化） | | パフォーマンス領域 | 8：ステークホルダー、チーム、開発アプローチとライフサイクル、計画、プロジェクト作業、デリバリー、測定、不確かさ | 7：ガバナンス、スコープ、スケジュール、ファイナンス、ステークホルダー、リソース、リスク | | プロセス | 本から外れた。PMIstandards+と別冊の実務ガイド（Process Groups、2022年、49プロセス）へ移行 | 規範的ではない（non-prescriptive）40のプロセスが本に復帰。5つのプロセス群は、5つのFocus Area（立上げ、計画、実行、監視・コントロール、終結）として戻った | | テーラリング | 原則の一つで、独立したセクションもあり | 原則からは外れたが、ガイダンスは維持 | | その他の構成 | モデル、方法、作成物のセクション | ツールと技法のセクション、AI・PMO・調達の内容を拡充 | ### 第8版で勉強した立場から見ると 第1回に書いたとおり、私は新試験を念頭にPMBOK第8版をベースに勉強を始め、日程がうまく合ったので改定前の試験を受けました。その立場から見えた違いを3つにまとめると、こうなります。 - **プロセスが戻ってきたのは、実用的な変化です**。第7版はプロセスを本の外（PMIstandards+、別冊のガイド）に出しましたが、第8版は40のプロセスを、立上げから終結までのFocus Areaとしてまとめ直しました。予測型の問題を解くとき、「今どの段階の作業なのか」を1冊の中で追いやすくなったと思います。 - **第8版の原則と、新しいECOの言葉が重なっています**。Focus on value（価値に焦点を当てる）はvalue-based deliveryのタスクと、Integrate sustainability（サステナビリティの統合）は4つのタスクに入ったサステナビリティのイネーブラーと対になっています。第8版を読んでおけば、新試験の用語に戸惑いません。 - **パフォーマンス領域に、ガバナンスとファイナンスが入りました**。試験でBusiness Environmentの比重が大きくなった流れと、同じ方向だと読めます。 AIの内容も、第8版で拡充されました。私のNotebookLM（現 Gemini Notebook）のノートブックのソースにも、「ALL the A.I. in the New PMBOK 8th Edition」というYouTube動画が入っています。ただ、先ほど述べたとおり、試験ではAIに独自のタスクはありません。 ### それでも、試験は1冊の本から出題されるわけではない PMIは、PMP試験が特定の1冊の本を基準に作られてはいないと、はっきり述べています。公式の参考資料トップ10も、PMBOKガイドとAgile Practice Guide（アジャイル実務ガイド）に、ほかの出版社の本8冊を加えた構成です。「新試験はPMBOK第8版ベース」という言い方は、正確ではありません。 ただ、つながりはあります。2026年版のECOは、プロジェクトの定義にPMBOK第8版の定義をそのまま使っています。「a temporary initiative in a unique context undertaken to create value」、つまり、固有の文脈の中で価値を生み出すために行う一時的な取り組みです。だから私は、第8版を試験範囲というより、**試験が使う言葉**として読むのが正しいと考えています。 ## PMIのAI標準とは 昨日届いたメールに戻りましょう。正式名称は『The Standard for Artificial Intelligence in Portfolio, Program, and Project Management』です。 | 項目 | 内容 | |---|---| | 発表 | 2026年6月9日 | | 分量 | 275ページ | | 価格 | PMI会員は無料、非会員はデジタル版$74.95 | | 8つの原則 | 戦略的価値、リスク、ガバナンス、人、倫理、ステークホルダー、最適化、データ品質 | | 5つのパフォーマンス領域 | ステークホルダーの期待、スコープ、アーキテクチャ、戦略の実行、リスク | | 特徴 | 人が判断のプロセスに関わり続けるhuman-in-the-loop、EU AI Act・ISO 42001との連携 | メールでは、この標準を、プロジェクト分野でANSIの承認を受けた初の、そして唯一のAI標準だと紹介しています。 とはいえ、AI標準がPMP試験の新しい領域になるわけではありません。新しいECOでは、AIに独自のタスクはなく、シナリオの中の文脈として登場します。ただ、会員なら無料なので、会社でAI導入を担当しているなら、一度目を通してみる価値はあります。 ## 今から準備するなら 第1回で「教材の版より先に、自分の試験日に適用されるECOを確認しよう」と書きましたが、改定後はこの言葉がさらに重要になりました。今から始める方におすすめする順番は、次のとおりです。 1. 2026年版のECOのPDFを自分で読みます。ドメインごとのタスクとイネーブラーが、そのまま勉強リストになります。 2. 講座、問題集、模擬試験が2026年7月の改定を反映しているか確認します。 3. Business Environmentと、アジャイル・ハイブリッドの問題に、より多くの時間を使います。 4. ケーススタディとグラフィックベースの問題は、別に練習します。やり方は[第9回](/ja/posts/pmp-case-study-questions)にあります。 5. 間違えた問題は、理由別に記録します。私のやり方は、[第6回](/ja/posts/pmp-error-log-method)にテンプレートと一緒にまとめました。 6. まだ申請していないなら、変わった経験の要件から確認してください。[第4回](/ja/posts/pmp-experience-application-audit)にまとめています。 ## おわりに 今回の改定を一言でまとめるなら、PMPが、プロジェクトを価値とビジネスの文脈の中で見ることを求め始めた、ということです。問題数は変わりませんが、試験が描くプロジェクト・マネージャー像はかなり変わりました。 次の第6回のテーマは、間違いノートです。第2回で「試験直前にいちばん役立った」と書いた、まさにそのノートをどう使っていたのかをまとめ、Wordのテンプレートも共有します。 **次の記事**：[第6回：PMP間違いノートの書き方](/ja/posts/pmp-error-log-method) **最初から読む**：[PMP合格体験記 第1部：7週間の準備と、Study Hall 60%台からPASSまで](/ja/posts/pmp-pass-review-part-1) ## 参考資料 - [PMI：PMP試験内容概要（ECO）2026、PDF](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf) - [PMIブログ：PMP試験改定のお知らせ](https://www.pmi.org/blog/pmp-exam-change) - [PMI：PMBOKガイドの案内ページ](https://www.pmi.org/standards/pmbok) - [PMI：AI標準の案内ページ](https://www.pmi.org/standards/artificial-intelligence) - [PMI：Project Management Professional（PMP）公式ページ](https://www.pmi.org/certifications/project-management-pmp) - [PMI資格ハンドブック、PDF](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/generic-certification-handbook.pdf) --- # PMP経歴の書き方とAudit（監査）：6月1日申請→6月9日承認、私のPM経歴はこうまとめました > PMPの受験資格と経歴の書き方、Audit（監査）の流れをまとめました。PMIの基準に合わせた経歴の記入例（日本語の下書き・英語）、6月1日の申請から6月9日の承認までの私のスケジュール、Audit対策チェックリストを紹介します。 _Slug: pmp-experience-application-audit · 2026-09-13_ 2026年6月1日の午後、PMPの受験申請書を提出しました。6月9日の夜11時に承認メールが届き、監査（Audit）はありませんでした。 [第3回](/ja/posts/pmp-application-pearson-vue-booking)ではPMIへの入会からPearson VUEの予約まで全体の流れを追いましたが、今回の第4回では、そのうち2つだけを深掘りします。申請書の経歴欄をどう埋めるか、そしてAuditに当たったら何を提出すればいいのか、です。 **3行まとめ**：学士号があれば、直近10年以内に36か月以上プロジェクトを率いた経験と、35時間の研修が必要です。経歴はプロジェクトごとに分けて、目的・期間・自分が率いたこと・結果が見えるように書き、重なる月は1回だけ数えます。Auditは無作為ですが誰にでも当たりうるので、最初から証明できることだけを書くのが、いちばん確実な対策です。 私は2026年6月に、改定前のルールで申請しました。受験資格は2026年7月の試験改定とあわせて一部変わったため、この記事の要件は現行のルール（2026年10月に確認）でまとめています。申請の直前に、[PMI公式のPMPページ](https://www.pmi.org/certifications/project-management-pmp)でもう一度確認してください。 ## 受験資格：学歴別の必要経験と35時間の研修 PMPでは、試験を受ける前にまず受験資格の審査があります。見られるのは2つ、プロジェクトを率いた経験と、プロジェクトマネジメントの研修35時間です。 | 最終学歴 | 必要な実務経験（直近10年、重複しない期間） | |---|---| | 高校卒業 | 60か月（5年） | | 短大・職業教育課程など（EQFレベル5、新設） | 48か月（4年） | | 学士以上 | 36か月（3年） | | PMIのGAC認定課程の学位 | 24か月（2年） | 私は学士号（経営学とソフトウェア工学のダブルメジャー）を持っているので、36か月のルートでした。ただ、私が申請した6月の時点では「直近8年以内の経験」しか認められず、2026年の改定後に「直近10年」へ広がりました。短大卒などを対象にした48か月のルートも、今回新しくできたものです。 ### 35時間の研修：12月1日からライブ講座のルールが変わる 経験とは別に、プロジェクトマネジメントの研修が35時間必要です。有効なCAPM資格があれば、この35時間は免除されます。 - **自分のペースで進めるオンライン講座**：どの機関の講座でも認められます。 - **ライブ講座**：講師が進行する対面・リアルタイムのオンライン授業は、2026年12月1日から、PMI認定トレーニング・パートナー（ATP）、中国のREP（登録教育プロバイダー）、認定を受けた高等教育課程で受けたものだけが認められます。 - **書籍と模擬試験**：これだけでは35時間を満たせません。 ライブ講座で35時間を満たすつもりなら、まずその機関がATPかどうかを確認してください。試験形式も含めた改定の全体像は、[第5回：2026年PMP改定まとめ](/ja/posts/pmp-2026-exam-changes-pmbok-8)で別にまとめています。 ## 私の経歴をPMPの基準で整理すると PMPの申請書は履歴書とは違います。会社名や肩書きではなく、「自分が率いたプロジェクト」を1件ずつ書きます。そのため、履歴書をそのまま写すより、プロジェクト単位に広げ直してみる必要があります。 私の経歴をこの基準で整理すると、次のとおりです。会社名はそのまま残し、顧客企業の名前はすべて伏せました。 | 期間 | 会社／役割 | PMPの観点で注目したい経験 | |---|---|---| | 2025年3月〜現在 | Concentrix Services Korea／Global Tech PM | エンタープライズ顧客のShopify・Magentoの構築と機能強化（優先順位、リスク、UAT、リリース、ローンチ後の安定化）。グローバル家電メーカーの顧客：運用バックログを104件→48件（−54%）、課題解決のリードタイムを27%短縮。グローバル・ビューティーグループの顧客：PDP生成SaaSの機能強化と、5ブランド・27のECサイトへのグローバル展開 | | 2023年4月〜2025年2月 | Hyperhire／Software Development PM | Web・アプリ・SaaS・ブロックチェーンのプロジェクト。インド、パキスタン、インドネシア、ナイジェリア、エチオピアの開発者と分散チームで働き、要件、バックログ、マイルストーン、QA、リリース計画を管理。プライベート・ブロックチェーンの第2フェーズ、NFTリワードアプリ（ウォレット機能、リワードのロジック）、ビザサービス・宿泊予約・ファッションECのアプリ、地域通貨コインなど | | 2021年1月〜2023年4月 | iCOOP（Natural Dream）／PM・オンライン事業マネージャー | 韓国のオープンマーケットNAVER（ネイバー）・Coupang（クーパン）への出店（営業、CS、SCM、WMS、デザイン、IT部門の調整）、SEOとキャンペーン、ESGキャンペーン（No Plastic） | | 2020年10月〜2023年4月 | FeelBetter／創業者 | 自分で運営したEC事業。4か月で売上約5,000万ウォン | 期間を足すだけでも、36か月は余裕で超えます。でも、PMIが数えるのは会社に在籍した期間ではなく「プロジェクトを率いた」期間で、重なる月は1回分しか認められません。 ### 重なる期間は1回だけ：私の経歴で計算してみると 私の経歴がちょうどいい例です。iCOOPで働いた2021年1月から2023年4月までの28か月は、FeelBetterを運営していた期間（2020年10月〜2023年4月）と完全に重なっています。両方の経歴を書いても、この28か月は1回しか数えません。2023年4月はHyperhireに入社した月とも重なるので、これも1か月として数えます。 ### 運用業務と起業経験は慎重に 数字がいいからといって、何でも経歴として認められるわけではありません。PMIは、日常的な運用業務や事務作業をプロジェクト経験として認めていません。 起業経験も同じです。4か月で売上約5,000万ウォンという数字は目を引きますが、事業の運営には毎日くり返す業務がたくさん混ざっています。こうした経験を書くなら、始まりと終わり、目標がはっきりした仕事だけを切り出して、プロジェクトとして説明する必要があります。 ## PMIが示す経歴の書き方の基準 PMIは2026年8月28日の公式ブログ記事で、経歴1件に盛り込むべき内容を次のように挙げています。 1. プロジェクトの目的 2. 期間 3. 自分がどう率いたか 4. 誰と一緒に働いたか 5. 自分が指揮した活動 6. 結果 これに、公式の案内でくり返し出てくるルールを3つ加えれば、基準はほぼ出そろいます。 - **プロジェクトは1件ずつ分けて**書きます。複数のプロジェクトを1つの欄にまとめません。 - **職業上の環境で行った仕事**だけが認められます。日常的な運用業務や事務作業は外します。 - **重なる月は1回だけ**数えます。 ### どのくらいの分量で書けばいいか PMIは、文字数や単語数の基準を公式には公開していません。対策サイトでは、以前のフォームはプロジェクト説明が200〜500ワード、2026年のフォームは「Role Summary」が100〜500ワードと案内されていますが、非公式の情報です。分量を合わせるより、上の6項目がもれなく入っているかを確かめるほうが大事です。 ### 書くときのコツ - 目的と結果は1文ずつ書きます。読んだ人が、どんなプロジェクトだったのかすぐにわかるようにします。 - 「参加した」より「率いた」「調整した」を使います。PMIが聞いているのは、自分の率い方と、指揮した活動です。 - 立上げ→計画→実行→監視・コントロール→終結の順に整理すると、抜けている段階がすぐに見えます。 - 結果に数字があれば入れます。「バックログ104件→48件（−54%）」のように。 - 社内用語より、PMPの用語（ステークホルダー、リスク、UAT、リリース）を使います。 ## 記入例：日本語で下書きして、英語で入力する 下は、私のConcentrixでの経歴のうち、グローバル・ビューティーグループの顧客企業のプロジェクトを、上の基準に合わせて書いてみた例です。実際の申請書に入力した文章を写したものではなく、履歴書の内容をPMIの形式で書き直した記入例です。期間などの細かい値は、ご自身の記録で埋めてください。 ### 日本語での下書き | 項目 | 記入例 | |---|---| | プロジェクト名 | グローバル・ビューティーグループ顧客企業向けPDP生成SaaSの機能強化とグローバル展開 | | 期間 | 開始年月〜終了年月 | | 目的 | 顧客企業の5ブランド・27のECサイトが同じPDP（商品詳細ページ）生成SaaSを使えるよう機能を強化し、グローバルに展開する | | 役割 | 顧客企業の本社チーム、各国の事業組織、グローバルベンダー、海外の技術チームの間で、優先順位・スケジュール・リスクに責任を持つPM | | 立上げ | 本社チーム・各国の組織と目標と優先順位を合意し、主要なステークホルダーを特定 | | 計画 | ブランド別・サイト別の展開計画、リスク登録簿、UATの基準を策定 | | 実行 | グローバルベンダーと海外の技術チームの開発・デプロイのスケジュールを調整 | | 監視・コントロール | リスクと優先順位の変更を追跡し、UATの結果にもとづく修正を管理 | | 終結 | リリースとローンチ後の安定化を主導し、ステークホルダーと結果を確認 | | 結果 | 5ブランド、27のECサイトに展開 | ### 申請書に入力する英語版 ```text Project title: PDP generator SaaS enhancement and global rollout Dates: [start month/year] - [end month/year] Objective: Enhance a product detail page (PDP) generator SaaS and roll it out to a global beauty group client's 5 brands and 27 e-commerce sites. Role: Project manager accountable for priorities, schedule and risks across the client's HQ teams, local business units, global vendors and overseas technical teams. What I led: - Initiating: Aligned objectives and priorities with HQ teams and local business units; identified key stakeholders. - Planning: Built the rollout plan by brand and site, the risk register and UAT criteria. - Executing: Coordinated development and deployment schedules with global vendors and overseas technical teams. - Monitoring and controlling: Tracked risks and priority changes; managed fixes based on UAT results. - Closing: Led releases and launch stabilization; confirmed results with stakeholders. Outcome: Rolled out to 5 brands and 27 e-commerce sites. ``` 英語版は140ワードほどです。対策サイトが示す範囲に収まっていて、何より、PMIが挙げた6項目（目的、期間、率い方、一緒に働いた人、指揮した活動、結果）がすべて入っています。 先に日本語で書くと「自分が実際にやったこと」に集中しやすく、英語にするときは文を短く区切るだけで済みます。この英語の文章は、Auditのときに上司が読んで確認するかもしれません。凝った表現より、事実をそのまま書くほうがいいです。 ## Audit：誰が、いつ、何を出すのか 申請書を出すとPMIが内容を審査し、一部はAudit（証明書類による審査）の対象に選ばれます。PMIの資格ハンドブックと公式の案内をまとめると、次のとおりです。 | 項目 | 内容 | |---|---| | 対象 | 無作為に選定。ただし、PMIは誰でもいつでも（資格取得後も含む）Auditでき、PMIの職員・ボランティアの申請はすべてAudit | | 通知 | 受験料を支払う前に、メールで | | 提出書類 | 学位（卒業）証明書のコピー、経歴ごとの上司・マネージャーによる確認、35時間の研修修了証 | | 進め方 | オンライン。mypmi.orgのダッシュボードにあるAuditパッケージで進め、上司はDocuSignで確認、書類はアップロード | | 提出期限 | 90日 | | 審査期間 | 書類をすべて提出してから約5〜7営業日 | | 通過したら | 通過した日から1年間の受験資格期間がスタート | | 未提出・不合格の場合 | 1年間の資格停止 | 書類を封筒に入れて郵送する方式ではなく、すべてオンラインで進みます。Auditの通知は支払いの前に届き、1年間の受験資格は、Auditを通過した日から数えます。 ### 私の場合：Auditなしで、8日で承認 6月1日の午後2時51分に、受付メールが届きました。最後の行には、こんな一文があります。「Applicants may be selected randomly for audit during the application process.」申請の過程で、無作為にAuditの対象に選ばれることがある、という意味です。 PMIの「Your PMP application has been received」メール。最後の行に、申請の過程で無作為にAuditの対象に選ばれることがあるという一文がある *2026年6月1日に届いたPMP申請の受付メール。最後の行が、無作為のAuditについての案内です。* そして6月9日の夜11時、承認メールが届きました。受付から約8日、体感では「1週間くらい」でした。Auditの通知はなく、次のステップである受験料の支払いの案内がそのまま書かれていました。 「Congratulations! Your PMP application has been accepted.」というメール。次のステップは受験料の支払いだという案内と、PMI会員向けの受験料割引のバナーが見える *2026年6月9日の夜に届いた申請承認メール。次のステップは受験料の支払いだと案内しています。* 2021年版の試験内容概要（ECO）には、Auditがなければ処理に約5日（暦日）かかると書かれていました。今の公式文書には、期間についての記載がありません。私の場合は8日だったので、1週間前後を見込んでおくと安心です。 Auditに当たらなかったのは、実力ではなく運です。無作為ですから。だからこそ、最初から「当たる」と想定して書くのが正解です。 ## Audit対策チェックリスト 申請ボタンを押す前に確認してみてください。全部にチェックが付けば、Auditのメールが来ても慌てることはありません。 - [ ] 経歴ごとに確認してくれる上司やマネージャーがいて、今も連絡がつく - [ ] その上司が自分の経歴の説明を読んで、そのとおりだと確認できる（誇張した文がない） - [ ] 学位（卒業）証明書のコピーをすぐに出せる - [ ] 35時間の研修修了証がある（研修機関と時間数が書かれている） - [ ] 経歴の期間が、履歴書やLinkedInと食い違っていない - [ ] 重なる月を2回数えていない - [ ] 日常的な運用業務や事務作業を、プロジェクトのように書いていない - [ ] 申請書に書いた内容を、別に保存してある Auditの通知を受けたら、90日以内に書類を提出しなければなりません。目標の試験日があるなら、Auditの可能性も見込んで、少し早めに申請してください。 ## おわりに 経歴欄は結局、「自分はプロジェクトを率いたことのある人間だ」と証明する場所です。かっこよく書くことより、上司が読んでそのまま確認できるように書くことが大切です。 次の第5回では、2026年7月9日から変わったPMP試験をまとめます。問題の構成やドメインの比重、PMBOK第7版と第8版の違いまで、表で比較します。 **次の記事**：[第5回：2026年PMP改定まとめ](/ja/posts/pmp-2026-exam-changes-pmbok-8) **最初から読む**：[PMP合格体験記 第1部：7週間の準備と、Study Hall 60%台からPASSまで](/ja/posts/pmp-pass-review-part-1) ## 参考資料 - [PMI：Project Management Professional（PMP）公式ページ（受験資格、35時間の研修のルール）](https://www.pmi.org/certifications/project-management-pmp) - [PMI：PMP試験内容概要（ECO）2026、PDF](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf) - [PMI資格ハンドブック（Auditの手続き）、PDF](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/generic-certification-handbook.pdf) - [PMIブログ：PMP試験改定のお知らせ](https://www.pmi.org/blog/pmp-exam-change) --- # PMPの受験申請からPearson VUEの予約まで：6月1日に申請、6月13日に予約完了（実際のメールを公開） > PMPの受験申請から承認、受験料の支払い、Pearson VUEでの韓国語試験の予約までにかかったのは12日。PMIへの入会から日程変更のルールまで、実際に届いたメールと一緒に順番にまとめました。 _Slug: pmp-application-pearson-vue-booking · 2026-09-11_ PMPの準備で意外とややこしいのは、勉強より書類と支払いです。PMIにはいつ入会するのか、受験料はいつ払うのか、試験の予約はPMIでするのか、Pearson VUEでするのか。初めてだと、手順の順番からして戸惑います。 私は6月1日に申請書を出し、6月13日の未明には試験の予約まで済ませました。その12日間にPMIとPearson VUEから届いたメールを、順番に公開します。申請書や予約の画面はログインしないと見られないので、この記事では、誰でも見られるPMIとPearson VUEのページ、そして私が実際に受け取ったメールで、手順をお見せします。 **3行まとめ**：手順は、PMI入会、受験申請書の提出、承認、受験料の支払い、受験資格のメール、Pearson VUEでの予約です。私は6月1日に申請し、6月9日に承認（監査なし）を受けたあと、6月12日に支払い、6月13日の午前0時56分に予約を終えました。会員価格のおかげで受験料は税込$445.50で、予約日は試験の30日前までなら無料で変更できます。 ## PMPの申請から予約までをひと目で 時刻はすべて韓国時間（日本時間と同じ）です。 申請書の提出自体には、お金はかかりません。受験料は、承認メールを受け取ってから払います。この過程で私が使ったお金は、次のとおりです。 | 項目 | 日付 | 支払額 | 備考 | |---|---|---|---| | PMIの会費 | 6月1日 | 別途 | 現在の韓国向けストアの通常価格は$139（私が払った金額ではありません） | | PMP受験料（会員価格） | 6月12日 | $445.50 | $405＋税$40.50 | | PMI Study Hall Essentials（任意） | 6月1日 | $53.90 | $49＋税$4.90、模擬試験用 | 費用の全体と領収書は、[第1部](/ja/posts/pmp-pass-review-part-1)にまとめています。 ## ステップ1：まずはPMIに入会 私は6月1日に、まずPMIに入会してから申請書を出しました。先に入会をすすめる理由は、受験料です。 PMIの入会歓迎メール。Get Familiar with Your Membershipという件名と、Welcome to PMI, JOOHYUNGの文言 *2026年6月1日に届いたPMIの入会歓迎メール。* 韓国からPMIのサイトにアクセスすると、PMPの受験料は会員$405、通常価格$655と表示されます。**差額は$250**で、会費は今の韓国向けストアの通常価格で$139です。会費を払っても、1回の受験で$111が残ります。私が6月に払った会員価格$405は、今も変わっていません。 韓国からアクセスしたPMIのPMP案内ページ。Member price $405、Full price $655、Apply Nowボタン *韓国からアクセスしたPMIのPMPページ。会員価格$405と通常価格$655が並んで表示されます。* 会員になると、こんな特典もついてきます。 - 再受験の受験料：会員$275、非会員$375 - 3年ごとの資格更新料：会員$60、非会員$150 - PMBOKガイド第8版のPDFが無料 - PMIのAI標準（The Standard for Artificial Intelligence in Portfolio, Program and Project Management）のPDFが無料 価格は地域によって異なります。米国のストアでは、受験料が会員$425、非会員$675で、会費は$164です。お住まいの地域でPMIのサイトに表示される価格を確認してください。 ## ステップ2〜3：受験申請書の提出と承認 ### 申請書には何を書くのか 申請書は、PMIのサイトでオンラインで作成します。大きく分けて、3つのことを書きます。 - **学歴**：最終学歴によって、必要なプロジェクト経験の長さが違います。高卒は60か月、準学士・職業教育の学位（新設された区分）は48か月、学士は36か月、GAC認定の学位は24か月です。 - **35時間のプロジェクトマネジメント教育**：受講した講座と受講時間を書きます。有効なCAPMを持っていれば、この要件は免除されます。 - **プロジェクト経験**：プロジェクトごとに分けて、プロジェクトの目的と期間、自分がどう率いたか、誰と働いたか、どんな活動を担当したか、結果はどうだったかを書きます。 経験は、直近10年以内のものだけが認められます。私が申請したときは8年でしたが、今は10年に延びました。申請手続きには強化された本人確認（enhanced verification）も加わり、支払いの前に、Personaというサービスで自撮り写真と政府発行の身分証明書を撮影して、本人確認をします。 35時間の教育は、2026年12月1日から認定基準が変わります。リアルタイム（ライブ）の講義は、PMIの認定トレーニングパートナー（ATP）や認定を受けた大学のプログラムなどで受けたものだけが認められ、自分のペースで進めるオンライン講義（self-paced）は、どこで受けたものでも引き続き認められます。本や模擬試験だけでは認められません。 経歴の書き方と監査（Audit）への備えは分量が多いので、[第4部：経歴の書き方と監査](/ja/posts/pmp-experience-application-audit)に分けてまとめました。 ### 6月1日：申請書の受付メール 申請書を提出すると、6月1日の午後2時51分に受付メールが届きました。 PMP申請書の受付メール。Your PMP application has been receivedという件名と、Applicants may be selected randomly for audit during the application processの一文 *2026年6月1日に届いたPMP申請書の受付メール。最後の行に、監査の対象者は無作為に選ばれることがあると書かれています。* メールの最後の一行が、地味に気になります。申請の過程で、無作為に監査の対象に選ばれることがある、という一文です。監査に当たると、学位証明書のコピー、経験ごとの上司の確認、研修の修了証明書を提出しなければなりません。対象者には受験料を払う前にメールで通知が来て、書類は90日以内にオンラインで提出します。 ### 6月9日：承認メール 6月9日の午後11時、申請が承認されたというメールが届きました。申請書を出してから8日、だいたい1週間で、監査はありませんでした。 PMP申請の承認メール。Congratulations, Your PMP application has been acceptedの文言、次のステップは受験料の支払いという案内、上部に会員限定の受験料価格のバナー *2026年6月9日に届いた承認メール。次のステップは受験料の支払いだと案内していて、いちばん上には会員限定の受験料価格のバナーがついています。* 内容はシンプルです。おめでとう、次のステップは受験料の支払い、支払いが済めば試験を予約できる、というものです。 PMIは2021年の文書で、監査がなければ審査に約5日（暦日）かかると案内していましたが、今の文書には期間が書かれていません。私のように1週間ちょっとかかることもあるので、試験日は余裕をもって考えておきましょう。 ## ステップ4〜5：受験料の支払いと受験資格のメール ### 6月12日：受験料$445.50を支払い 承認から3日後の6月12日に、受験料を払いました。会員価格$405に税$40.50がついて、合計$445.50です。 PMP受験料の決済メール。購入日2026年6月12日、Project Management Professional (PMP) Exam $405.00、税$40.50、合計$445.50 *2026年6月12日に届いたPMP受験料の決済メール。$405に税$40.50で、合計$445.50です。注文番号は隠してあります。* 支払ったあとで事情が変わっても、手はあります。支払日から30日以内で、その間に試験を予約して受験していなければ、返金を申請できます。 ### 6月13日午前0時23分：受験資格のメール 支払いの翌日、午前0時23分に「You are eligible to take the PMP® exam」というメールが届きました。試験の予約に必要な情報は、すべてこのメールに入っています。 PMPの受験資格メール。身分証明書の氏名JOOHYUNG IM、Eligibility Expiration Date 06 Jun 2027、Delivery Mode Center-Based Testing (CBT)、30日以内の日程変更・キャンセルには70ドルの手数料がかかるという案内 *2026年6月13日の午前0時23分に届いた受験資格のメール。受験資格の有効期限は2027年6月6日まで、受験方式はテストセンター（CBT）となっています。Eligibility IDは隠してあります。* このメールで確認すべきことは、4つです。 - **身分証明書の氏名**：「Name exactly as it appears on your identification」の欄の名前が、試験当日に持っていく身分証明書と完全に一致していなければなりません。 - **受験資格の有効期限**：私の場合は2027年6月6日まででした。受験資格の期間は1年で、その間に最大3回まで受験できます。 - **受験方式**：Center-Based Testing（CBT）、つまりテストセンターでの受験と書かれています。 - **US$70のルール**：試験日の30日以内に日程を変更またはキャンセルすると、US$70がかかります。30日より前なら無料です。 メールには、座席は先着順なので、日にちが決まったらすぐに予約するように、という案内もあります。私はそのとおりにしました。 ## ステップ6：Pearson VUEで試験を予約する ### 予約はPMIから始まり、Pearson VUEで終わる 試験はPearson VUEで予約しますが、出発点はPMIです。手順はこうです。 1. PMIのダッシュボード（myPMI）で**Schedule Exam**をクリックします。 2. Pearson VUEのサイトに移動します。 3. 事前承認済みの試験（Pre-approved Exams）の一覧から、PMPを選びます。 4. テストセンターで受けるか、オンライン監督試験（OnVUE）で受けるかを選びます。 5. 試験の言語を選びます。私は韓国語を選びました。 6. テストセンターを選び、日時を決めます。 7. 予約内容を確認し、Checkoutの段階で注文を確定すると、予約が完了します。 支払いの直後にPearson VUEで試験が表示されなくても、慌てないでください。PMIの案内によると、受験資格がPearson VUEに反映されるまで、最大24時間かかることがあります。 Pearson VUEのPMI試験案内ページ。試験の予約・変更・キャンセルは、Continue to log inボタンを押して受験プログラムのサイトに移動してから始めるという案内 *Pearson VUEのPMI案内ページ。予約・変更・キャンセルのどれも、ログインボタンを押すとPMIのサイトに移動して始まります。* ### テストセンターを事前に探す Pearson VUEの「Find a test center」で、PMIの試験を実施しているセンターを事前に検索できます。ただし画面の案内文にあるとおり、この検索では、センターの営業時間や空席はわかりません。それが見られるのは、PMIから受験資格が与えられたあと、ログインして予約するときです。すべてのセンターがすべてのPMI試験を実施しているわけでもなく、PMPは一部のセンターでしか受けられません。 Pearson VUEのFind a test center画面と案内文。PMPのような試験は一部のセンターでしか実施されず、営業時間と空席はPMIが受験資格を与えたあとでしか確認できないという内容 *Pearson VUEの「Find a test center」の案内文。営業時間と空席は、PMIが受験資格を与えたあとでしか見られないと書かれています。* 私が受験したムギョロ（무교로）の住所で検索すると、いちばん上にPearson Professional Centers-Seoul（中区ムギョロ21、The Exchange Seoul 6階）が出てきます。韓国内では、ほかにLEXIS EXAM CENTRE Seoul（瑞草区カンナムデロ53ギル）とLEXIS EXAM CENTRE Busanも表示されます。ただし検索結果は変わることがありますし、結果に出ているからといって、そのセンターでPMPを受けられるとは限りません。受験資格を得たあと、予約画面で必ず確認してください。 Pearson VUEのテストセンター検索結果。1番がPearson Professional Centers-Seoul、6F The Exchange Seoul, 21 Mugyo-ro, Jung-gu, Seoul 04520で、韓国の地図つき *「21 Mugyo-ro, Jung-gu, Seoul」で検索した結果。1番が、私が受験したPearson Professional Centers-Seoulです。* ### 受験資格のメールから33分後に予約完了 受験資格のメールを受け取ってから33分後、6月13日の午前0時56分に予約確認メールが届きました。試験は7月3日（金）の午前10時15分で、予約した日から約3週間後です。言語は韓国語、会場はムギョロのPearson Professional Center Seoulです。 ## ステップ7：予約確認メールと日程変更・キャンセルのルール ### 予約確認メール 予約を終えると、Pearson VUEから確認メールが届きます。私に届いたメールは韓国語でした。 Pearson VUEの韓国語の予約確認メール。試験PMP-CBT 韓国語（KOR）、2026年7月3日（金）午前10時15分、予約時間270分、Pearson Professional Center Seoul、中区ムギョロ21 The Exchange Seoul 6階 *2026年6月13日に届いたPearson VUEの予約確認メール。注文番号、PMI ID、登録IDは隠してあります。* 予約時間が270分なのは、230分の試験（改定前）に、試験前のチュートリアルと同意手続き、試験後のアンケートの時間が加わっているからです。メールには当日のルールも書かれています。30分前に到着すること。15分を超えて遅れると入室を断られることがあり、その場合は受験料が返ってこないこと。氏名・写真・署名のある、政府発行の身分証明書の原本を持ってくること。試験当日の話は、[第2部](/ja/posts/pmp-pass-review-part-2)に詳しく書きました。 ### 日程変更・キャンセルのルール | いつ変更するか | 日程変更・キャンセル | |---|---| | 試験日の30日より前 | 無料 | | 試験日の30日以内 | US$70＋税 | | 試験の48時間以内 | 変更・キャンセル不可。欠席すると受験料は全額失効 | 変更とキャンセルも、予約と同じくPMIから始めて、Pearson VUEで行います。私は約3週間後の日程で予約したので、最初から30日以内だったことになります。日にちを変える事情が出てきたら、US$70を払うしかなかったわけです。試験日は慎重に選んでください。 ### 韓国語で受験するときに知っておきたいこと - **英語の原文を見る**：問題も画面もすべて韓国語で表示され、各問題にあるExhibitボタンを押すと、英語の原文を見られます。韓国語と英語を並べて表示する方式ではありません。 - **言語は予約後に変更できない**：予約した試験の言語は、あとから変えられません。変えるにはキャンセルして予約し直す必要があり、タイミングによっては上の手数料がかかります。Checkoutの前に、言語を必ず確認してください。 - **オンライン試験の監督**：韓国からオンラインで韓国語の試験を受ける場合、監督はPearson VUEではなく、ATAが担当します。 ## 申請前に準備しておくものチェックリスト 申請書を開く前に、次のものをそろえておくと、ずっと早く終わります。 - **学歴の情報**：学校、学位、卒業時期。監査に当たると、学位証明書のコピーが必要です。 - **35時間の教育の記録**：講座名、教育機関、受講時間、修了証 - **プロジェクト経験**：直近10年以内の、プロジェクトごとの期間、目的、自分の役割、担当した活動、結果 - **経験を確認してくれる人**：監査に当たると、経験ごとに上司の確認が必要です。 - **身分証明書のローマ字氏名**：申請書の氏名と、試験当日に持っていく身分証明書の氏名が、完全に一致している必要があります。パスポートのローマ字表記に合わせるのが、いちばん確実です。 - **ドル決済ができるカード**：会費も受験料も、ドルで支払います。 - **試験の言語と方式**：どの言語で受けるか、テストセンターに行くかオンラインで受けるか。言語は予約後に変更できません。 - **試験日の候補**：受験資格は1年ありますが、座席は先着順で、30日以内の変更には手数料がかかります。 ## おわりに 手順さえわかれば、PMPの申請はメール6通で終わります。入会、受付、承認、支払い、受験資格、予約確認。私は申請書を出してから12日で、試験日まで決まりました。 次の第4部では、申請書でいちばん時間がかかる経歴の書き方と、監査への備えを取り上げます。申請する前に、今の試験がどう変わったのかを先に知りたいなら、[第5部：2026年PMP試験改定まとめ](/ja/posts/pmp-2026-exam-changes-pmbok-8)から読んでください。 **次の記事**：[PMP経歴の書き方とAudit（監査）](/ja/posts/pmp-experience-application-audit) **最初から読む**：[PMP合格体験記 第1部：7週間の準備と、Study Hall 60%台からPASSまで](/ja/posts/pmp-pass-review-part-1) ## 参考資料 - [PMI公式のPMP案内ページ](https://www.pmi.org/certifications/project-management-pmp) - [PMI Certification Handbook（PDF）](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/generic-certification-handbook.pdf) — 日程変更・キャンセル、返金、試験言語、身分証明書の規定 - [2026 PMP Examination Content Outline（PDF）](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf) — 受験資格の要件 - [Pearson VUE：PMI試験の案内](https://www.pearsonvue.com/us/en/pmi.html) - [Pearson VUE：PMI試験のテストセンター検索](https://find-seats.pearsonvue.com/clients/PMI/testcenters) --- # ヤンジェのクリョンガク：チャンポンを食べに行って、きゅうりの和え物にひれ伏した日 > チャンポン、カンジャジャン、そして予想外の伏兵、きゅうりの和え物。レビュー7,900件で評価4.83、親切さまでそろったヤンジェドンの中華料理店クリョンガクの訪問記。きゅうりの和え物は選択肢じゃなく、必須だ。 _Slug: yangjae-guryonggak-jjamppong-ganjjajang · 2026-09-10_ 中華料理店に行くと、いつも同じことで悩む。チャンポンか、ジャージャー麺か。 ヤンジェドン（良才洞）の**クリョンガク**（구룡각）で、その悩みをあっさり終わらせた。両方頼んだのだ。チャンポンひとつ、カンジャジャン（汁気の少ないジャージャー麺）ひとつ。ここまでは計画どおりだった。 計画になかったのは、**きゅうりの和え物**（オイムチム）だった。サイドのつもりで頼んだこの一皿が、その日の主役の座を奪っていった。 **3行まとめ**：チャンポンは海鮮たっぷり、カンジャジャンは目玉焼きまでのった王道。でも本当の決め手は**きゅうりの和え物**。頼まなかったら、絶対に後悔する。スタッフまで親切で、ヤンジェドンの名店と呼ぶのに異論はない。 ## 扉を開けると、思ったより「レストラン」だ
濃いグレーのパネル壁と無垢材の天井、照明の下にテーブルが置かれたクリョンガクの静かな部屋
無垢材の天井に、濃い色のパネル壁。町中華と呼ぶには、ちょっとおめかししすぎだ。
町中華を想像して入ると、ちょっと面食らう。無垢材の天井、濃いグレーのパネル壁、照明の下に整然と並ぶテーブル。1階から3階まで使う大きな店なので、団体の集まりも余裕だ。NAVER（ネイバー）のレビューで「**店内が広い**」（3,351人）と「**インテリアがおしゃれ**」（3,347人）が並んで上位に入っている理由は、入った瞬間にわかる。 ## 第1ラウンド：チャンポン
エビ、イカ、ムール貝、玉ねぎ、きくらげがのった真っ赤なチャンポン
エビ、イカ、ムール貝、きくらげ。スープより先に、海鮮があいさつしてくる。
チャンポンが届くと、スープより先に海鮮が目に入る。ぷりぷりのエビ、切り込みを入れたイカ、ムール貝、そしてきくらげ。スープはただ辛いだけじゃなく、野菜と海鮮から出た甘みがベースにあるから、スプーンが止まらない。麺を食べ終えても、ついスープを何さじかすくってしまうチャンポンだ。 ## 第2ラウンド：カンジャジャン
目玉焼きをのせた麺と、別添えのカンジャジャンのソース
麺の上に目玉焼き、ソースは別。カンジャジャンの王道。
カンジャジャンのソース、目玉焼きをのせた麺、チャンポンが並ぶテーブルを真上から撮った写真
チャンポンとカンジャジャン、両方頼むのが正解だ。
カンジャジャンは麺の上に**目玉焼き**がのって、ソースは別で出てくる。水を加えずにその場で炒めたジャージャーソースを麺にかけて混ぜると、玉ねぎの甘みとチュンジャン（黒みそ）の香ばしさが、つやつやと麺に絡みつく。NAVERプレイスがこの店をひとことでまとめた言葉が、まさにぴったりだ。「**チャンポンとジャージャー麺の完璧な組み合わせ**」。 ## どんでん返しの主役：きゅうりの和え物
ラー油のたれで和えた、大ぶりのきゅうりときくらげの和え物
今日のMVP。大きめに切ったきゅうりときくらげを、ラー油のたれで和えてある。
そして、こいつが出てきた。大きめに切ったきゅうりときくらげを**ラー油のたれ**で和えた、中華風のきゅうりの和え物。ひと口食べた瞬間、シャキッとしたきゅうりが口の中をさっぱり洗い流し、あとからピリ辛で酸味のあるたれが追いかけてくる。 これがなぜ決め手なのかというと、**チャンポンとカンジャジャンの合間に口をリセットしてくれるから**だ。チャンポンをひと口、きゅうりをひと口、カンジャジャンをひと口、またきゅうり。このルーティンに入れば、2杯を食べ終えるまで飽きない。結論はひとつ。**きゅうりの和え物は必須**。
テーブルに置かれた、たくあんとザーサイの基本のおかず、ナプキン入れと水のボトル
基本のおかずは、たくあんとザーサイ。すっきりとスタート。
## 味と同じくらい記憶に残ったもの：人 この店にまた行きたい理由は、料理だけじゃない。**スタッフが親切だ**。夕食どきに寄ったのだが、入ってから出るまで、対応がずっと変わらず親切だった。大きな店ほど接客が事務的になりがちなのに、クリョンガクはその逆だった。 ## ほかのお客さんの評価は？ 自分の舌だけを信じろと言うには、この店の実績は華やかすぎる。2026年9月時点のNAVERプレイスの数字を集めてみた。 - ⭐ **来店者評価4.83** · レビュー**7,918件**（写真付きレビューだけで6,779件） - 🥇 いちばん多く選ばれたキーワード：「**料理がおいしい**」7,520人、「**食材が新鮮**」4,153人 - 🙂 「**親切**」2,393人、「**コスパがいい**」2,321人 - 📝 レビューでいちばん多く言及されたテーマ：味（6,073件）＞満足度（3,328件）＞サービス（1,195件） レビューが8,000件近く積み上がっても評価4.8台をキープしているということは、一度や二度たまたま運がよかった店じゃないということだ。私ひとりの感想ではなかった。 ## メニューと価格 | メニュー | 価格 | | --- | --- | | 神コスパ・ジャージャー麺 | 8,000ウォン | | 神コスパ・チャンポン | 10,000ウォン | | **クリョン三鮮カンジャジャン**（海鮮入り） | **11,000ウォン** | | **クリョン三鮮チャンポン**（海鮮入り） | **12,000ウォン** | | クリョン・チャドルチャンポン（牛バラ肉入り） | 13,000ウォン | | 三鮮チャーハン | 11,000ウォン | | クリョン・タンスユク（韓国式酢豚、小／中） | 21,000ウォン／34,000ウォン | | 油淋鶏（小／中） | 32,000ウォン／42,000ウォン | 持ち込み料無料（コルキージフリー）のイベントもやっているので、料理をいくつか頼んで集まりをするのにもいい。 ## 店舗情報 📍 **クリョンガク ヤンジェドン店** · ソウル瑞草区ノニョンノ61（1〜3階） - 🚇 **アクセス**：新盆唐線ヤンジェシミネスプ（良才市民の森）駅2番出口から徒歩約14分（約950m） - 🕐 **営業時間**：毎日11:10〜22:00、**ブレイクタイム15:00〜17:00** - 💰 **価格**：チャンポン10,000ウォンから、カンジャジャン11,000ウォン - ✅ **設備・サービス**：駐車場・バレーパーキング、予約、団体席、子ども用椅子、待合スペース、Wi-Fi - 🗺️ **地図**：[NAVERマップ](https://map.naver.com/p/entry/place/1695355269) · [Googleマップ](https://www.google.com/maps/search/?api=1&query=37.4755842%2C127.0463507) ヤンジェドンでもう一食探しているなら、歩いて2分の[オヌルド・ポッサムカルグクス ヤンジェ店](/ja/posts/yangjae-oneuldo-bossam-kalguksu)（오늘도보쌈칼국수 양재점）もおすすめだ。 メニュー価格と営業時間は、2026年9月の訪問時点のNAVERプレイスの情報だ。きゅうりの和え物の値段は、お店で確認しよう。 ## Jaydenのひとこと評 > チャンポンとカンジャジャンは約束を守り、きゅうりの和え物は期待を裏切った。いい意味で。 - **チャンポン・カンジャジャン**：★★★★★ - **きゅうりの和え物**：★★★★★（必須） - **親切さ**：★★★★★ - **再訪**：あり。ヤンジェドンで中華が食べたくなったら、迷わずここだ。 --- # ソクスドンのウロンサムパプ・イガネ：「タニシぎっしり」の本当の意味 > 土鍋のカンテンジャンは、タニシが半分、味噌が半分。ザルいっぱいの葉野菜に、豚肉の甘辛炒めとプルコギまで並ぶアニャン・ソクスドンのウロンサムパプ・イガネ。ここは本当にタニシがぎっしり。絶対食べるべし。 _Slug: anyang-ureong-ssambap-igane · 2026-09-09_ サムパプ（葉野菜でご飯とおかずを包んで食べる料理）の店でタニシ入りの味噌を頼むと、たいていこうなる。スプーンで味噌をぐるぐるかき混ぜながら、**タニシを探す**。ひとつ出てくればうれしいし、ふたつ出てきたらラッキーな日だ。 アニャン（安養）・ソクスドンの**ウロンサムパプ・イガネ**（우렁쌈밥이가네）では、そのゲームが成り立たない。探す必要がない。トゥッペギ（韓国の土鍋）の表面が、もうタニシで覆われている。 **3行まとめ**：タニシ入りカンテンジャン（煮詰めた濃い韓国味噌）のトゥッペギに、**タニシが本当にぎっしり**入っている。山盛りの葉野菜にチェユク（豚肉の甘辛炒め）とプルコギまで並んで、ボリューム満点。ほんとにおいしいから、近くに行くなら絶対食べるべし。 ## テーブルが足りないほどのごちそう
鉄板にのった赤いチェユクポックムとゴマをふったプルコギ、ふたつのトゥッペギとおかずが並ぶテーブル
鉄板のチェユク、ゴマたっぷりのプルコギ、トゥッペギがふたつ。テーブルはすぐにいっぱいになる。
土曜のお昼。席について注文すると、テーブルはあっという間に狭くなる。鉄板の上でジュージューいう**赤いチェユクポックム**、ゴマをたっぷりふった**プルコギ**、トゥッペギがふたつ、そしてザルいっぱいの葉野菜。そのすき間を、おかずの小皿がびっしり埋めていく。 ## 主役はトゥッペギの中にいる
タニシがこんもりのったカンテンジャンのトゥッペギと、豆腐入りテンジャンチゲ、プルコギの皿
左のトゥッペギの黒い粒は、全部タニシ。味噌よりタニシが先に目に入る。
写真のトゥッペギに見える黒い粒は、全部**タニシ**だ。味噌よりタニシが先に見えるカンテンジャンなんて、初めてだった。ひとさじすくえば、コリコリのタニシが3、4個ずつついてきて、塩気のきいた味噌がそのすき間を埋める。 **ここは、本当にタニシがぎっしりだ**。かむたびにプリッと弾ける食感がちゃんと生きていて、カンテンジャンがおかずというより、メイン料理に思えてくる。豆腐入りのテンジャンチゲは別に出てくるので、カンテンジャンは包む用、チゲはスプーンですくってご飯のおともにすればいい。 ## 包む順番は、こうしてみよう
ザルに盛られたサンチュや葉野菜、青唐辛子の横に、チェユク、プルコギ、トゥッペギとご飯が並ぶ様子
葉野菜はたっぷり。青唐辛子も一緒に出てくる。
1. 大きな葉野菜を一枚広げる。 2. ご飯を少しのせて、チェユクかプルコギをひと切れのせる。 3. 最後に**タニシ入りカンテンジャンを大きくひとさじ**のせる。 4. 仕上げに青唐辛子をひとかじり。 肉の甘みに、タニシのコリコリ感と味噌の塩気が重なる。この組み合わせを一度味わえば、サムパプの店でタニシ入りカンテンジャンにわざわざ専用の名前がついている理由に、納得がいく。 ## ほかのお客さんの評価は？ 2026年9月時点のNAVER（ネイバー）プレイスで、この店に積み上がった数字がこちら。 - ⭐ **訪問者評価4.23** · レビュー**570件** - 🥇 「**料理がおいしい**」242人、「**食材が新鮮**」134人 - 🍚 「**量が多い**」82人、「**コスパがいい**」64人 - 📝 レビューでいちばん多く触れられたテーマ：味（128件）＞満足度（86件）＞料理の量（28件） NAVERプレイスの一行まとめは「**新鮮な葉野菜とタニシ味噌の夢のコンビ**」。味、新鮮さ、量。私が感じた3つが、そのまま数字に刻まれている。 ## メニューと価格 | メニュー | 価格 | | --- | --- | | **タニシサムパプ定食** | **17,000ウォン** | | チュムルロク（味付け肉）のタニシサムパプ | 15,000ウォン | | チョムチム（ピリ辛の甘酢和え）のタニシサムパプ | 15,000ウォン | | サムギョプサルのタニシサムパプ | 20,000ウォン | | プルコギのタニシサムパプ | 20,000ウォン | | チャドル（牛バラ肉）とタニシのテンジャンチゲ | 8,000ウォン | | トゥッペギ・ヌンイプルコギ（コウタケ入りプルコギの土鍋） | 10,000ウォン | | タニシのチョムチム（中／大） | 20,000ウォン／30,000ウォン | | ヌンイ（コウタケ）とタニシのチョンゴル鍋（大） | 40,000ウォン | ## 店舗情報 📍 **ウロンサムパプ・イガネ**（우렁쌈밥이가네） · 경기 안양시 만안구 삼막로 47 (석수동) - 🚇 **アクセス**：1号線クァナク（冠岳）駅2番出口から徒歩約14分（約780m）。サムマクサというお寺へ続くサムマク路の入り口にあるので、**クァナクサン（冠岳山）やサムソンサン（三聖山）の登山の前後**に寄るのにぴったり。 - 🕐 **営業時間**：11:00〜21:00（ラストオーダー20:00）、**毎週木曜定休** - 💰 **価格**：タニシサムパプ定食17,000ウォン、サムパプ各種15,000〜20,000ウォン - ✅ **便利情報**：駐車場あり - 🗺️ **地図**：[NAVERマップ](https://map.naver.com/p/entry/place/31051666) · [Googleマップ](https://www.google.com/maps/search/?api=1&query=37.4237003%2C126.9125037) タニシのサムパプが気に入ったなら、江原道ホンチョン（洪川）の[トンマッコル食堂のチュクミポックム（イイダコ炒め）とタニシサムパプ](/ja/posts/hongcheon-dongmakgol-jjukkumi-ureong-ssambap)も一緒に保存しておこう。 メニュー価格と営業時間は、2026年9月時点のNAVERプレイスの情報だ。行く前に一度チェックしておこう。 ## Jaydenのひとこと評 > タニシを探そうとスプーンを入れたら、タニシのほうが先に私を見つけに来た。 - **タニシ密度**：★★★★★ - **ボリューム**：★★★★★ - **リピート**：あり。山帰りの日は、ここまで下りてくるつもりだ。 --- # ヘバンチョンのザ・バック・フードトラック：ナムサン帰りの目玉焼きバーガー、眺めはおまけ > Nソウルタワーを見上げながら歩いた先、ヘバンチョンの坂のてっぺんで出会ったバーガー店。目玉焼きをのせた分厚いバーガーに、ソウルの街を一望できるテラスまで。本当においしい。 _Slug: haebangchon-the-back-food-truck-burger · 2026-09-08_ バーガーひとつのために坂を上る人なんていない。少なくとも、私はそう思っていた。 その日はナムサン（南山）の散策路を歩いていた。空は青く、Nソウルタワーは手が届きそうなほど近かった。歩いているうちにお腹がすいてきて、ヘバンチョン（解放村）の坂のてっぺんに**ザ・バック・フードトラック**（더백푸드트럭）があった。 結果的に、この坂は上る価値があった。 **3行まとめ**：イテウォン（梨泰院）のすぐ隣、坂の町ヘバンチョンにある手作りバーガーの店。目玉焼きをのせた分厚いバーガーが**本当においしい**。テラスからはソウルの街が一望できるので、ナムサン散歩とセットで行こう。 ## 道のりからしてコースの一部
青空の下、緑の森の上にそびえるNソウルタワー
行く途中に見上げたNソウルタワー。この日は空がいい仕事をした。
薄暗い店内から見た、開いた窓の向こうの緑の木々と青空
店の窓越しにも、ナムサンのふもとの緑が入ってくる。
ヘバンチョンは、ナムサンのすぐ下、イテウォンとヨンサン（龍山）のあいだの坂に広がる町だ。狭い路地と階段、上り坂が続く。だから、ここのおいしい店はたいてい「**道のりまで含めての体験**」になる。Nソウルタワーを見上げながら歩いて、下りてきてバーガーを食べるコース。これだけで半日が埋まる。 ## バーガー、登場
バンズの上に、黄身がまんまるに残った目玉焼きをのせて串で留めた手作りバーガー
黄身がきれいに残った目玉焼き。串一本でなんとか持ちこたえている高さ。
バーガーの上に、**目玉焼き**が帽子のようにのって出てくる。黄身はぷるんと丸いままで、縁はカリッと揚げ焼きになっている。バーガーのど真ん中に串が一本刺さっていて、それがなければ崩れてしまいそうな高さだ。
半分に切ったバーガーの断面。卵、チーズ、トマト、野菜、分厚いパティが層になって見える
半分に切るとこうなる。卵、チーズ、トマト、そして分厚いパティ。
半分に切ってみると、断面がこのバーガーの自己紹介になっている。卵、とろけたチーズ、トマト、野菜、そして**分厚いパティ**。かぶりつけば黄身が流れ出して、パティの肉汁と混ざり合う。手がベタベタになっても、それだけの価値は十分ある。**本当においしい**。 ## この店の隠れメニュー：眺め
テラスの手すりの向こうに広がるソウルの街並みと、雲のかかった空
テラスに立つと、ソウルが足元に広がる。
ヘバンチョンの坂から見下ろした住宅街の屋根と、遠くに見える高層ビル
ヘバンチョンの屋根の向こうに、ヨンサンのビル群。
1階と2階の両方を使った店で、テラスに出ると**ソウルの街が一望**できる。ヘバンチョンの住宅街の屋根の向こうにビル群が広がり、天気がいい日は雲まで絵になる。バーガーを食べに来たはずが、気づけば写真ばかり撮っている店だ。 ## ほかのお客さんの評価は？ 2026年9月時点のNAVER（ネイバー）プレイスの数字だ。眺めへの反応が特に目を引く。 - ⭐ **訪問者評価4.36** · レビュー**2,442件** - 🥇 「**料理がおいしい**」965人 - 🌆 「**眺めがいい**」696人（2番目に多いキーワード） - 🙂 「**食材が新鮮**」238人、「**接客が親切**」208人 - 📝 レビューでいちばん多く触れられたテーマ：味（632件）＞満足度（510件）＞**眺望（168件）** NAVERプレイスの一行まとめは「**ヘバンチョンを代表する人気店に登りつめた**」。バーガー店のレビューで「眺望」が3番目に多く語られるなんて、なかなかない。 ## メニューと価格 | メニュー | 価格 | | --- | --- | | アメリカンチーズバーガー（140g） | 9,500ウォン | | **ザ・バックバーガー** | **10,800ウォン** | | ベーコンチーズバーガー（140g） | 10,800ウォン | | モッツァレラチーズバーガー | 10,800ウォン | | アメリカンチーズバーガー ダブル | 12,800ウォン | | メキシカンバーガー | 14,800ウォン | | キューバンサンドイッチ | 8,500ウォン | | チリチーズフライ／トリュフオイルフレンチフライ | 13,900ウォン | | フィッシュ＆チップス | 18,900ウォン | ## 店舗情報 📍 **ザ・バック・フードトラック**（더백푸드트럭） · 서울 용산구 신흥로20길 45（1・2階） - 🚇 **アクセス**：最寄りの地下鉄駅である4号線スクテイック（淑大入口）駅や6号線ノクサピョン駅からも、1km以上離れた坂の上にある。タクシーかマウルバス（住宅街を走る小型の路線バス）を使うか、**ナムサン散歩とセットで**歩いて行くのがおすすめ。 - 🕐 **営業時間**：火〜日11:30〜21:30、**ブレイクタイム15:00〜17:00**、ラストオーダー20:30、**毎週月曜定休**（旧正月・チュソクの連休は時間が変わることあり） - 💰 **価格**：バーガー9,500〜14,800ウォン - ✅ **便利情報**：テイクアウト、デリバリー、団体利用、モバイル決済 - 🗺️ **地図**：[NAVERマップ](https://map.naver.com/p/entry/place/36473368) · [Googleマップ](https://www.google.com/maps/search/?api=1&query=37.5474801%2C126.9840426) メニュー価格と営業時間は、2026年9月時点のNAVERプレイスの情報だ。行く前に一度チェックしておこう。 ## Jaydenのひとこと評 > バーガーひとつのために坂を上る人。それは私だった。そして、また上るつもりだ。 - **バーガー**：★★★★★ - **眺め**：★★★★★ - **リピート**：あり。次は夕暮れどきに、テラス席を狙うつもりだ。 --- # シンサドンのタラート：豚の骨を塔のように積んだレンセープ、カロスキルに行くなら絶対ここ > タイ語で「市場」という意味のタラート。ネオンの下、豚の背骨が塔のように積み上がったレンセープに、エビのパッタイ、目玉焼きをのせたガパオまで。評価4.89、シンサドンのタイ料理の名店。 _Slug: sinsa-dallat-thai-food · 2026-09-07_ **タラート**（딸랏、ตลาด）は、タイ語で「市場」という意味だ。 名前を知ってから入ると、インテリアに納得がいく。紫のネオン、ステンレスのテーブル、折りたたみ椅子、壁に貼られたブリキの看板。バンコクのナイトマーケットのど真ん中に座っている気分だ。そしてまもなく、テーブルの上に**タワー**がひとつ建つ。 **3行まとめ**：豚の背骨をタワーのように積み上げた**レンセープ**は、見た目から味までこの店の看板だ。パッタイやガパオといった定番もしっかりおいしい。カロスキルやアックジョン（狎鴎亭）ロデオ方面に行くなら、**絶対に食べておくべきシンサドン（新沙洞）の名店**。 ## バンコクのナイトマーケットへ瞬間移動
紫の照明とペンダントライトの下に、ステンレスのテーブルと折りたたみ椅子が並ぶタラートの店内
紫のネオンとステンレスのテーブル。ナイトマーケットの雰囲気そのまま。
「Travel to Thailand」のブリキ看板とタイ語のウイスキーの看板、赤い車のドアの飾りが貼られた壁
「Travel to Thailand」のブリキ看板に、赤い車のドアまで。小物のひとつひとつが本気だ。
2階にある店内は、照明から小物まで、タイの市場をそのまま運んできた。壁にはタイの守護神が描かれた「Travel to Thailand」のブリキ看板、タイ語のウイスキーの看板、赤い自動車のドアが貼りつけてある。NAVER（ネイバー）のレビューで「**インテリアがおしゃれ**」を選んだ人が477人もいるわけだ。 ## 今日のタワー：レンセープ
澄んだスープの上に、青唐辛子とにんにくのたれをのせた豚の背骨が高く積み上がったレンセープ
これが1人前じゃないとわかっていても、圧倒される。レンセープ登場。
**レンセープ**（เล้งแซ่บ）は、豚の背骨をじっくり煮込んで澄んだスープに浸し、その上に青唐辛子・にんにく・ライム・パクチーのたれをたっぷりかけた、バンコクスタイルの料理だ。タラートのレンセープは、骨を**タワーのように高く積み上げて**出てくる。テーブルに置かれた瞬間、全員がまずスマホを取り出す。 骨のすき間についた肉は、箸を当てただけでするっと外れるほどやわらかい。酸味と辛みのきいたたれが脂ののった肉をさっぱり引き締め、下に敷かれたスープは飲むほどに爽快だ。値段は35,000ウォンだが、量がとにかく多いので、**2〜3人でシェアするメイン料理**だと思えばいい。 ## 定番もしっかりおいしい
エビともやし、砕いたピーナッツ、ライムを添えたパッタイ
丸ごとのエビをのせたパッタイ。ピーナッツとライムはお好みで。
白いご飯の上に半熟の目玉焼きとガパオを盛った皿。奥にレンセープが見える
目玉焼きをのせたガパオライス。黄身を割って混ぜて食べる。
**パッタイ**は、ぷりぷりのエビともやしがたっぷり。横に砕いたピーナッツとライムが別添えで出てくる。ライムを搾ってピーナッツを混ぜれば、甘酸っぱさと香ばしさのバランスがぴたりと決まる。**ガパオライス**は、白いご飯の上に縁がカリッとした目玉焼きをのせてくれる。黄身を割ってピリ辛のガパオと混ぜれば、レンセープの合間にご飯が欲しくなったときにぴったりだ。
ステンレスのテーブルに並んだレンセープ、ガパオライス、パッタイ、米麺とソースを真上から撮った写真
これくらい並べてこそ、タラートを満喫したと言える。
## ほかのお客さんの評価は？ 2026年9月時点のNAVERプレイスの数字。今回紹介する10軒の中でも、指折りの成績だ。 - ⭐ **来店者評価4.89** · レビュー**1,710件** - 🥇 「**料理がおいしい**」1,579人 - 🇹🇭 「**本場の味に近い**」690人 - 🍜 「**食材が新鮮**」669人、「**量が多い**」579人 - 📝 レビューでいちばん多く言及されたテーマ：味（1,211件）＞満足度（683件）＞サービス（124件） 「本場の味に近い」というキーワードが2番目に多いのがポイントだ。タイ料理店へのほめ言葉として、これ以上確かなものはない。 ## メニューと価格 | メニュー | 価格 | | --- | --- | | **レンセープ**（看板） | **35,000ウォン** | | トムヤムクン（看板） | 22,000ウォン | | **オリジナル・パッタイ**（看板） | **13,000ウォン** | | 豚足丼（カオカームー、看板） | 13,000ウォン | | 牛すね肉のライスヌードル（看板） | 12,000ウォン | | クンパッポンカリー（エビのカレー炒め） | 25,000ウォン | | ガイヤーン（タイ風グリルチキン） | 24,000ウォン | | コームーヤーン（タイ風豚トロ焼き） | 22,000ウォン | | マクチャンのガパオ炒め（マクチャン・パッガパオ・ムーサップ） | 18,000ウォン | | トムヤム海鮮ライスヌードル | 14,000ウォン | ## 店舗情報 📍 **タラート** · ソウル江南区アックジョンノ50キル22、2階（新沙洞） - 🚇 **アクセス**：水仁盆唐線アックジョンロデオ駅6番出口から徒歩約5分（約330m）。カロスキルからロデオ方面へ抜ける散策コースに組み込みやすい。 - 🕐 **営業時間**：火〜日 11:30〜22:00（ラストオーダー21:30）、**毎週月曜定休** - 💰 **価格**：パッタイ・ライスヌードル12,000〜14,000ウォン、レンセープ35,000ウォン - ✅ **設備・サービス**：予約、テイクアウト、団体利用、子ども用椅子、Wi-Fi、モバイル決済 - 🗺️ **地図**：[NAVERマップ](https://map.naver.com/p/entry/place/1879588862) · [Googleマップ](https://www.google.com/maps/search/?api=1&query=37.5268676%2C127.0377153) メニュー価格と営業時間は、2026年9月時点のNAVERプレイスの情報だ。行く前に一度チェックしておこう。 ## Jaydenのひとこと評 > シンサドンのど真ん中で、バンコクのナイトマーケットの骨タワーを崩した。カロスキルに行くなら、このタワーはぜひ一度崩してみてほしい。 - **レンセープ**：★★★★★ - **本場感**：★★★★★ - **再訪**：あり。次はトムヤムクンとカオカームーの番だ。 --- # ホンデのプルナンファンソ・コプチャン：モドゥムコプチャンひと皿に「最高」しか出てこなかった > ホンデイック駅から4分、レビュー5,000件で評価4.84。コプチャン・テチャンなど色々な部位がひと皿にのるモドゥムコプチャン、海苔たっぷりのポックンパ、締めのラミョンまで。モドゥムコプチャン最高！ _Slug: hongdae-ppulnan-hwangso-gopchang · 2026-09-06_ 金曜の夜、ホンデ（弘大）。コプチャン（牛の小腸焼き）の店は多い。多すぎるのが問題だ。 悩んだ末に入ったのは**プルナンファンソ・コプチャン**（뿔난황소곱창）。名前（「怒った雄牛」という意味）からして怒っているのに、コプチャンはまったく怒っていなかった。むしろ、すごくおとなしかった。臭みひとつなく。 **3行まとめ**：コプチャン、テチャン（牛の大腸）など、いろいろな部位がひとつの鉄板にのる**モドゥムコプチャン（盛り合わせ）が最高**。臭みがなくて香ばしく、コプ（中の脂）がぎっしり詰まっている。最後は海苔たっぷりのポックンパ（焼き飯）で締めてこそ、コースが完成する。 ## ひとつの鉄板に全部のってくる：モドゥムコプチャン
丸い鉄板の上に、コプチャン、テチャン、トック、サツマイモ、ニラ、キムチがぐるりと並ぶモドゥムコプチャン
コプチャンとテチャン、そしてサツマイモとトック。この円の中に、今夜の晩ごはんが全部ある。
丸い鉄板の上に、コプチャンとテチャンがぐるりと円を描いて出てくる。縁にはサツマイモ、トック（韓国の餅）、ニラ、キムチ。モドゥムをひとつ頼むだけで、**部位ごとの食べ比べが一度に**できるので、コプチャン初心者にも上級者にも正解と言えるメニューだ。
こんがり焼けたコプチャンとテチャン、ニラとキムチのアップ
こんがり色づいたら食べどき。テチャンはもう少し待とう。
こんがり焼けたコプチャンをひとつつまむと、**コプがぎっしり**。かむほどに香ばしさが広がり、コプチャンの店でいちばん心配な臭みがない。テチャンはもう少しカリッと焼いてから食べると、脂の甘みが爆発する。焼いたサツマイモとトックは、コプチャンの合間に口を休ませてくれる脇役だ。 正直な感想は、ひとことで足りる。**最高**。 ## コプチャン店の掟：締めはポックンパ
鉄板の上で赤く炒め、刻み海苔とゴマをたっぷりのせたポックンパ
鉄板に残った脂で炒めて、海苔とゴマをたっぷり。
貝とホタテ、ねぎをのせた赤いラミョンが入った黒い鍋
それでも物足りなければ、ラミョン（韓国ラーメン）まで。貝とホタテ入り。
コプチャンを食べ終えても、まだ終わりじゃない。鉄板に残ったコプチャンの脂とタレでご飯を炒め、その上に**刻み海苔とゴマを山のように**のせてくれる。底に少し焦げついたところをこそげて食べるのがポイントだ。 それでも物足りない日はラミョンだ。貝とホタテ入りの赤いラミョンでスープまで押さえれば、コプチャン→ポックンパ→ラミョンと続く**ホンデのコプチャン・フルコース**が完成する。 ## ほかのお客さんの評価は？ 2026年9月時点のNAVER（ネイバー）プレイスの数字。コプチャンの店があふれるホンデでも、ひときわ目立つ。 - ⭐ **訪問者評価4.84** · レビュー**5,012件** - 🥇 「**料理がおいしい**」4,675人 - 🥩 「**肉の質がいい**」2,906人 - 🙂 「**接客が親切**」1,624人、「**店内が広い**」1,248人 - 👃 「**臭みが少ない**」797人 - 📝 レビューでいちばん多く触れられたテーマ：味（3,852件）＞満足度（2,064件）＞サービス（823件） 「臭みが少ない」というキーワードを800人近くが押したというのは、コプチャンの店にとって最高の勲章だ。私が感じた第一印象と、まったく同じ。 ## メニューと価格 | メニュー | 価格 | | --- | --- | | **モドゥムコプチャン**（看板） | **23,000ウォン** | | 韓牛コプチャン（看板） | 23,000ウォン | | 牛マクチャン（第四胃・ギアラ） | 22,000ウォン | | 牛テチャン | 22,000ウォン | | トゥギャン（上ミノ） | 24,000ウォン | ## 店舗情報 📍 **プルナンファンソ・コプチャン ホンデ店**（뿔난황소곱창 홍대점） · 서울 마포구 와우산로29바길 16 - 🚇 **アクセス**：2号線・空港鉄道ホンデイック（弘大入口）駅7番出口から徒歩約4分（約220m） - 🕐 **営業時間**：火〜木16:00〜23:00、金・土16:00〜24:00、日16:00〜22:00（ラストオーダーは閉店1時間前）、**毎週月曜定休** - 💰 **価格**：コプチャン・マクチャン・テチャン22,000〜24,000ウォン - ✅ **便利情報**：予約可、団体利用可、Wi-Fiあり - 🗺️ **地図**：[NAVERマップ](https://map.naver.com/p/entry/place/1779698070) · [Googleマップ](https://www.google.com/maps/search/?api=1&query=37.5557977%2C126.925909) コプチャンをスープでも楽しみたいなら、ひとさじごとにコプがついてくる[ナクソンデのワンコプチャン・ネジャンタン（ホルモンスープ）](/ja/posts/nakseongdae-wang-gopchang-naejangtang)のレビューもある。 メニュー価格と営業時間は、2026年9月時点のNAVERプレイスの情報だ。ポックンパとラミョンの値段は、お店で確認しよう。 ## Jaydenのひとこと評 > 名前は怒った雄牛なのに、食べ終えて店を出てきた人は笑っていた。 - **モドゥムコプチャン**：★★★★★ - **臭みのなさ**：★★★★★ - **リピート**：あり。ホンデでコプチャンが食べたくなったら、ほかの選択肢はない。 --- # チェギドンのサカヤ：明太子ケランチムが決め手。これはマジでハンパない > 桜の天井の下、深夜2時まで明かりがともる居酒屋。串焼きもうまいが、この店の本当の決め手は明太子がごろっとのったふわふわの卵蒸しだ。ひと月で2回通った理由。 _Slug: jegidong-sakaya-myeongran-gyeranjjim · 2026-09-05_ ひと月のあいだに、同じ居酒屋に2回行った。2回とも、日付が変わってからだった。 理由はひとつ。**明太子ケランチム**（韓国式の卵蒸し）。初めて食べた日からずっと頭を離れず、結局またあの扉を開けて入った。チェギドン（祭基洞）駅のすぐ前、天井を桜が埋め尽くす居酒屋、**サカヤ**（사까야）だ。 **3行まとめ**：サカヤは**串焼きとケランチム**に尽きる。なかでも明太子がごろっとのった**明太子ケランチムが、この店の決め手**。マジでハンパない。深夜2時まで開いているから、遅めの2軒目に完璧だ。 ## 扉を開ければ、桜が咲く
天井を覆う白い桜の飾りの下に、赤い提灯が下がる居酒屋の店内
天井いっぱいの桜、その下に赤い提灯。季節に関係なく、ここはいつも春だ。
紙の灯りの下、日本酒や酒瓶がぎっしり並んだ棚
日本酒と酒瓶がぎっしり詰まった棚。選ぶのも楽しい。
店に入ると、天井が**桜で埋め尽くされて**いる。その下に赤い提灯、和風の絵、紙の灯り、ぎっしり並んだ酒瓶。季節に関係なく、この中はいつも春の夜だ。
赤い和傘と紙の灯りが掛かり、波の絵やポスターが貼られた壁
赤い和紙の傘と波の絵。小物を眺めるだけでしばらく楽しめる。
日本語で日本酒の銘柄が書かれた紺色の布の垂れ幕と、竹の窓辺の席
日本酒の銘柄が書かれた紺色の垂れ幕と、竹の窓辺。
壁のあちこちにあるポスターや小物のおかげで、待ち時間も退屈しない。NAVER（ネイバー）のレビューで「**会話しやすい**」と「**インテリアがおしゃれ**」が上位キーワードに入っているのも納得だ。 ## この店の決め手：明太子ケランチム
土鍋いっぱいにふんわり膨らんだ卵蒸しの真ん中に、赤い明太子がのっている
ふわふわに膨らんだ卵蒸しの真ん中に、明太子がひとかたまり。これが決め手だ。
熱々の土鍋の中で卵蒸しがふっくらと膨らみ、その真ん中に**赤い明太子がひとかたまり**のっている。スプーンで明太子を少し崩して、卵と一緒にすくって食べる。 ふわふわでやわらかい卵のあいだから、**塩気のきいた、プチプチはじける明太子**が飛び込んできた瞬間、これがなぜ決め手なのかがわかる。卵のやさしい味を明太子がぐっと引き上げ、明太子の塩気を卵がやわらかく包み込む。ひとさじ、酒をひと口、またひとさじ。止まらない。 **明太子ケランチム、ほんとに決め手だ。ハンパない**。サカヤに行くなら、これは絶対に頼むべきだ。 ## 串焼きは基本。でも、その基本が手堅い
黒い皿にのった丸ごとエビの串、長ねぎと肉の串、ミニトマトのベーコン巻き串、そしてレモン
丸ごとエビ、長ねぎと肉、ミニトマトのベーコン巻き。レモンひと切れまで添えて。
キャベツの上にのった、こんがり焼けたベーコン巻き串とソース
こんがり焼けたベーコン巻き串。下に敷かれたキャベツまで食べてしまう。
串焼きは、表面がこんがりきつね色に焼けて出てくる。丸ごとエビの串、長ねぎを挟んだ肉の串、ミニトマトをベーコンで巻いた串まで。特に**ミニトマトのベーコン巻き**は、ひと口かじった瞬間にトマトの汁がはじけて、ベーコンの塩気と混ざり合う。キャベツの上にのって出てくるベーコン巻き串は、ソースがしみたキャベツまでつい食べてしまう。
カリッと揚がった唐揚げと、醤油だれの小皿
カリッとした唐揚げ。ビールを呼ぶ味。
カリッと揚げた**唐揚げ**も、ビールのつまみにぴったりだ。 ## ほかのお客さんの評価は？ 2026年9月時点のNAVERプレイスの数字。レビュー数はまだ少ないが、それだけ**知る人ぞ知る地元の居酒屋**ということでもある。 - ⭐ **来店者評価4.23** · レビュー**100件** - 🥇 「**料理がおいしい**」56人 - 🙂 「**親切**」22人 - 🍶 「**お酒の種類が豊富**」14人、「**会話しやすい**」13人、「**インテリアがおしゃれ**」12人 NAVERプレイスは、この店を「**高級おでんの真髄、関西おでん**」とまとめている。串焼きとケランチムだけでも十分だったが、3回目はおでんまで頼んでみるつもりだ。 ## 店舗情報 📍 **サカヤ** · ソウル東大門区ムハンノ36キル32、1階 - 🚇 **アクセス**：1号線チェギドン駅6番出口から徒歩約2分（約150m） - 🕐 **営業時間**：月〜土 17:30〜翌02:00、**毎週日曜定休** - 💰 **価格**：NAVERプレイスに登録されている焼き鳥の価格は1本4,000ウォン。明太子ケランチムやほかのメニューは、店のメニュー表で確認しよう。 - ✅ **雰囲気**：遅めの2軒目、ふたりで静かに話すのにいい店 - 🗺️ **地図**：[NAVERマップ](https://map.naver.com/p/entry/place/1675368341) · [Googleマップ](https://www.google.com/maps/search/?api=1&query=37.5774683%2C127.0323611) 営業時間と価格は、2026年9月時点のNAVERプレイスの情報だ。行く前に一度チェックしておこう。 ## Jaydenのひとこと評 > 串焼き目当てで行ったのに、ケランチムのためにまた行った。 - **明太子ケランチム**：★★★★★（決め手） - **串焼き**：★★★★★ - **雰囲気**：★★★★★ - **再訪**：もう2回行った。次はおでんまで。 --- # ホンチョンのトンマッコル食堂：オーシャンワールドに行ったら絶対これ、チュクミポックムとタニシサムパプ > ビバルディパークのオーシャンワールドで思いきり遊ぶと、お腹と背中がくっつきそうになる。そんなときに行くべき店。ピリ辛のイイダコ炒めをタニシ入りカンテンジャンと一緒に葉野菜で包んで食べる、ホンチョンのトンマッコル食堂。 _Slug: hongcheon-dongmakgol-jjukkumi-ureong-ssambap · 2026-09-04_ ウォーターパークで半日遊んで出てくると、体がこう言いだす。「**ごはん。今すぐ。たくさん。**」 ホンチョン（洪川）のビバルディパークにある**オーシャンワールド**に行った日なら、そのサインへの正解は決まっている。ピリ辛のチュクミポックム（イイダコの甘辛炒め）を、タニシ入りのカンテンジャン（煮詰めた濃い韓国味噌）と一緒に葉野菜で包んで食べる、サムパプ（包みご飯）のごちそう。ホンチョンのソミョンにある**トンマッコル食堂**（동막골식당）だ。 **3行まとめ**：看板メニューの**チュクミポックム＋タニシサムパプ**（16,000ウォン）が、この店のすべてであり正解。葉野菜はたっぷりで、タニシ入りカンテンジャンも中身がぎっしり。オーシャンワールドに行ったら、これは絶対食べるべし。 ## こんなふうに出てくる
黒い皿ふたつに盛られたチュクミポックム、葉野菜、ニンニク、タニシ入りカンテンジャンのトゥッペギが並ぶテーブルを真上から撮った写真
チュクミポックムがふた皿、葉野菜がどっさり、そしてタニシ入りカンテンジャン。
席に着くと、真っ赤な**チュクミポックム**が黒い皿に盛られて出てくる。横にはサンチュ、エゴマの葉、青唐辛子、ニンニクが山盛りで、小さなトゥッペギ（韓国の土鍋）には**タニシ入りカンテンジャン**。おかずの小皿まで並ぶと、テーブルにすき間はなくなる。 ## 主役その1：チュクミポックム
玉ねぎや長ねぎと一緒に真っ赤に炒め、小ねぎをのせたチュクミポックムと、タニシ入りカンテンジャンのトゥッペギ
つやつやのチュクミポックム。プリプリの足がどっさり。
チュクミは玉ねぎ、長ねぎと一緒に真っ赤に炒められ、上には小ねぎがぱらりと散らしてある。タレはつやつやで、**チュクミはプリプリ**。辛さがガツンとくるけれど、それで終わりじゃない。あとから甘みが支えてくれるので、箸が止まらない。 ## 主役その2：タニシサムパプ
サンチュ、エゴマの葉、小ねぎの横に置かれたチュクミポックムとタニシ入りカンテンジャンのトゥッペギ
葉野菜は惜しみなく。
キムチ、ナムル、青唐辛子のおかずと、チュクミポックム、タニシ入りカンテンジャンが並ぶテーブル
キムチ、ナムル、青唐辛子まで。おかずもたっぷり。
この店でチュクミポックムをちゃんと味わう方法は、**サム**（葉野菜で包むこと）だ。 1. サンチュの上にエゴマの葉を一枚重ねる。 2. ご飯を少し、チュクミポックムをたっぷりのせる。 3. **タニシ入りカンテンジャン**をひとさじのせる。 4. ニンニクか青唐辛子を添えて、ひと口で。 ピリ辛のチュクミに、塩気のきいたカンテンジャンとコリコリのタニシが重なると、辛さはまろやかになって、うまみは倍になる。チュクミだけで食べるのと包んで食べるのとでは、まるで別の料理だ。タニシサムパプという名前は伊達じゃない。 ## ほかのお客さんの評価は？ 2026年9月時点のNAVER（ネイバー）プレイスの数字だ。旅先の店らしく、「量」と「駐車」の話が目立つ。 - ⭐ **訪問者評価4.31** · レビュー**221件** - 🥇 「**料理がおいしい**」129人 - 🥬 「**食材が新鮮**」57人、「**量が多い**」53人 - 🙂 「**接客が親切**」34人、「**コスパがいい**」32人 - 🚗 「**駐車しやすい**」29人 NAVERプレイスの一行まとめは「**舌をとりこにするタニシサムパプの風味**」。車で移動する旅行者にとって、「駐車のしやすさ」は味と同じくらい大事な情報だ。 ## メニューと価格 | メニュー | 価格 | | --- | --- | | **タニシサムパプ＋チュクミポックム**（看板） | **16,000ウォン** | | タニシサムパプ＋チェユクポックム（豚肉の甘辛炒め） | 14,000ウォン | | 鉄板チュクミ | 16,000ウォン | | 鉄板チュクミ＋サムギョプサル | 18,000ウォン | | チュクミビビンバ | 12,000ウォン | | スンデクッ（スンデ入りスープ） | 11,000ウォン | | タニシテンジャン（タニシ入りの韓国味噌料理） | 10,000ウォン | | スンドゥブ | 10,000ウォン | ## 店舗情報 📍 **トンマッコル食堂**（동막골식당） · 강원 홍천군 서면 한서로 473 - 🚗 **アクセス**：公共交通機関より**車**が便利。ビバルディパークのオーシャンワールドから直線距離で約10kmなので、行き帰りに寄りやすい。 - 🕐 **営業時間**：火〜日11:00〜20:00（**ブレイクタイム14:00〜17:00**）、月曜は11:00〜14:00のランチのみ - 💰 **価格**：チュクミポックムのタニシサムパプ16,000ウォン、チェユクのタニシサムパプ14,000ウォン - ✅ **便利情報**：駐車しやすい（レビューより） - 🗺️ **地図**：[NAVERマップ](https://map.naver.com/p/entry/place/15745153) · [Googleマップ](https://www.google.com/maps/search/?api=1&query=37.6803262%2C127.5805732) ブレイクタイムが3時間もあるので、オーシャンワールドの予定と合わせて、**ランチは午後2時前**に着くのがおすすめ。タニシサムパプが食べたいけれどソウル近郊にいるなら、アニャン（安養）・ソクスドンの[ウロンサムパプ・イガネ](/ja/posts/anyang-ureong-ssambap-igane)もある。 メニュー価格と営業時間は、2026年9月時点のNAVERプレイスの情報だ。繁忙期は変わることもあるので、行く前に一度チェックしておこう。 ## Jaydenのひとこと評 > オーシャンワールドで水を飲み、トンマッコルでご飯を食べた。その日の本当のハイライトは、ふたつ目のほうだった。 - **チュクミポックム**：★★★★★ - **タニシ入りカンテンジャンのサム**：★★★★★ - **リピート**：あり。ホンチョンに行くなら、絶対コースに入れる。 --- # ヤンジェのオヌルド・ポッサムカルグクス：麦ごはんはセルフ、キムチチゲは夜でも食べられる > ポッサムとカルグクスの店なのに、キムチチゲが夜でも食べられる。麦ごはんはセルフバーで好きなだけ、おかずは全部お店の手づくり。評価4.85、ヤンジェ店は最高！ _Slug: yangjae-oneuldo-bossam-kalguksu · 2026-09-03_ キムチチゲが食べたくなる日がある。問題は、食べたくなるのが**夜**だということだ。 昼なら石を投げれば当たるほどあるキムチチゲが、夜になると不思議と見つからない。夜は肉料理や酒のつまみ中心のメニューに切り替える店が多いからだ。ところがヤンジェドン（良才洞）の**オヌルド・ポッサムカルグクス**（오늘도보쌈칼국수）は、夜でもキムチチゲを煮込んでくれる。しかも、麦ごはんが**セルフ**だ。 **3行まとめ**：ポッサム（ゆで豚）とカルグクス（韓国式の手打ち麺）の店なのに、**キムチチゲが夜でも頼める**。**麦ごはんはセルフバー**で好きなだけ、おかずは全部お店の手づくり。オヌルド・ポッサムカルグクスのヤンジェ店、最高！ ## 夜7時50分のキムチチゲ
白菜キムチと肉が入った真っ赤なキムチチゲが、鍋でぐつぐつ煮えている様子
よく漬かった白菜キムチに、肉。夜でもこのひと鍋が食べられる。
鍋ごとぐつぐつ煮立って出てくるキムチチゲ。よく漬かった**白菜キムチ**が大ぶりに入っていて、スープのあいだから肉がのぞく。スープは酸味があってピリッと辛く、キムチがくたくたになるまで煮込むほど、味に深みが出てくる。夜に食べたかったのは、まさにこれだ。 ## この店の秘密兵器：セルフの麦ごはん
ステンレスのたらいに入った麦ごはん
セルフバーの麦ごはん。好きなだけよそってくればいい。
「麦ごはんはセルフバーをご利用ください。おかずはすべて店内で手づくりしています」と書かれた案内文
「おかずはすべて店内で手づくりしています」
店の一角に**セルフバー**がある。麦ごはんがたらいごと置いてあって、好きなだけよそってこられる。案内文にはこう書いてある。「**おかずはすべて店内で手づくりしています。おかずはセルフで、お好きなだけどうぞ！**」
「オヌルド・ポッサムのおいしい召し上がり方」と「麦ごはんのおいしい召し上がり方」が書かれたテーブルの案内板
テーブルごとに「おいしい召し上がり方」の案内板がある。
テーブルの案内板には、麦ごはんの食べ方まで親切に書いてある。**麦ごはんにヨルムキムチ（若大根のキムチ）、豆もやし、コチュジャン、ごま油を入れて、まんべんなく混ぜる**。そのとおりにやれば、セルフビビンバの完成だ。ここにキムチチゲのスープをひとさじ添えても、よく合う。
木のテーブルに並んだ白菜キムチ、ナムル、豆もやしのおかずの皿
店で手づくりしているというおかず。麦ごはんのビビンバの具にもなる。
## もともとの看板メニューは、ポッサムとカルグクス 店名のとおり、本来の主力は**ポッサムとカルグクス**だ。案内板に書いてあるカルグクスのコツも覚えておこう。**貝が口を開けたら先に貝を引き上げて食べ、スープがぐらぐら煮立ったらカルグクスの麺を入れて約6分**。ピリッと辛くしたいなら、タデギ（唐辛子ベースの辛い薬味）をくださいと頼めばいい。 お昼には、ランチ限定の**カブリポッサム定食**と**トンジュクカルグクス定食**もあって、どちらも10,000ウォンだ（カブリは豚の肩ロースとロースのあいだの部位、トンジュクは小ぶりの二枚貝）。昼はコスパ、夜はキムチチゲとポッサム。一日じゅう頼りになる店だ。 ## ほかのお客さんの評価は？ 2026年9月時点のNAVER（ネイバー）プレイスの数字だ。「量」と「コスパ」が特に強い。 - ⭐ **来店者評価4.85** · レビュー**2,219件** - 🥇 「**料理がおいしい**」2,098人 - 🥬 「**食材が新鮮**」1,150人 - 🍚 「**量が多い**」1,012人、「**コスパがいい**」788人 - 🪑 「**店内が広い**」774人、「**親切**」538人 NAVERプレイスの一行まとめは「**新鮮な食材でつくった、真心たっぷりの料理**」。店でおかずを手づくりしているという案内文と、ぴったり重なる。 ## メニューと価格 | メニュー | 価格 | | --- | --- | | 【ランチ限定】カブリポッサム定食 | 10,000ウォン | | 【ランチ限定】トンジュクカルグクス定食 | 10,000ウォン | | 山盛りトンジュクカルグクス＋麦ごはん | 10,000ウォン | | **カブリポッサム**（小／中／大） | **41,000ウォン／49,000ウォン／58,000ウォン** | | サクサク海鮮揚げチヂミ | 20,000ウォン | | クァメギ（半干しの魚）のポッサム三合・統営産カキのポッサム・イイダコのポッサム（季節メニュー） | 50,000〜58,000ウォン | ## 店舗情報 📍 **オヌルド・ポッサムカルグクス ヤンジェ店** · ソウル瑞草区マバンノ10ギル58（1階） - 🚇 **アクセス**：新盆唐線ヤンジェシミネスプ（良才市民の森）駅2番出口から徒歩約13分（約830m） - 🕐 **営業時間**：11:00〜22:00、平日は**ブレイクタイム15:00〜17:00**（ラストオーダー14:30／21:30）、週末はブレイクタイムなし - 💰 **価格**：ランチ限定メニュー10,000ウォン、カブリポッサム41,000ウォンから - ✅ **設備・サービス**：駐車場、予約、団体利用、テイクアウト、デリバリー、子ども用椅子、Wi-Fi、スマホ決済 - 🗺️ **地図**：[NAVERマップ](https://map.naver.com/p/entry/place/2003637016) · [Googleマップ](https://www.google.com/maps/search/?api=1&query=37.475095%2C127.0451299) 歩いて2分のところには、チャンポン、カンジャジャン、きゅうりの和え物がおいしい[クリョンガク](/ja/posts/yangjae-guryonggak-jjamppong-ganjjajang)（구룡각）もある。ヤンジェドンで2軒はしごするコースとして、保存しておこう。 メニュー価格と営業時間は、2026年9月時点のNAVERプレイスの情報で、旧正月やチュソク（秋夕）の連休には変わることもある。キムチチゲの値段は、お店で確認しよう。 ## Jaydenのひとこと評 > 夜にキムチチゲが食べられる店は貴重だ。そのうえ麦ごはんがセルフなら、その店はもう宝物だ。 - **キムチチゲ**：★★★★★ - **セルフの麦ごはん**：★★★★★ - **再訪**：あり。次はカルグクスに6分のタイマーをセットしてみるつもりだ。 --- # ムルレのチョルサンジャン：鉄を扱う街のスープは裏切らない > 鉄工所の路地が続くムルレドンで、店名からして「鉄」の字が入ったチョルサンジャン。平壌冷麺、ビビン冷麺、スユク、マンドゥまで全部うまい。レビュー2,500件超えでも評価4.9を守る店。 _Slug: mullae-cheolsanjang-pyongyang-naengmyeon · 2026-09-02_ 昔から持っている、うまい店の仮説がひとつある。 **「鉄を扱う街は、汁物がうまい。」** 熱く溶けた鉄と油のにおいの中で一日を耐え抜く人たちは、腹にたまる熱々の一杯と、体の中をすっと冷ましてくれる冷たい一杯を求める。そんな街の食堂は、いい加減にとったスープでは生き残れない。鉄工所の路地で知られるムルレドン（文来洞）、そして名前からして**鉄**（チョル）の字が入った**チョルサンジャン**（철산장）は、この仮説を完璧に証明してくれた。 **3行まとめ**：**平壌冷麺、ビビン冷麺、スユク**（ゆで肉）、全部うまい。澄んで奥深いスープが、この店の土台だ。レビューが2,500件を超えても**評価4.9**。今回紹介する10軒の中で最高点だ。 ## 1杯目：平壌冷麺
澄んだスープにそば粉の麺、薄切りの肉、半熟卵、きゅうりをのせた平壌冷麺
澄んだスープ、そば粉の麺、トッピングの肉。平壌冷麺はこうして淡白に始まる。
ステンレスの器の中で、澄んだスープがゆらゆらと揺れる。その上にそば粉の麺、トッピングの肉、半熟卵、きゅうり。平壌冷麺はひと口目が物足りない、とよく言われる。ところが2口目、3口目から、**肉のスープの深い味**がじわじわと上がってくる。麺は、ぷつぷつと切れるそば特有の食感がしっかり生きている。 平壌冷麺が初めてなら、これだけ覚えておこう。**酢とからしはひとまずガマン、まずはスープを3口**。 ## 2杯目：ビビン冷麺
真っ赤なたれの上に半熟卵とごまをのせたビビン冷麺。奥に平壌冷麺の器が見える
真っ赤なビビン冷麺。平壌冷麺と交互に食べると終わりがない。
平壌冷麺が淡白さの極みなら、ビビン冷麺はその正反対の極みだ。真っ赤なたれの上に、半熟卵とごまがのっている。甘辛いたれがそば粉の麺にぴたっと絡み、**平壌冷麺をひと口、ビビン冷麺をひと口**と交互に食べれば、辛さと爽快さのループが延々と続く。ふたりで行くなら、1杯ずつ頼んでシェアするのが正解だ。 ## 3皿目：スユクとマンドゥ
白い皿に盛られた薄切りのスユクと、大ぶりの平壌マンドゥ2個
薄切りのスユクと大ぶりの平壌マンドゥ。冷麺店の実力はここに表れる。
冷麺店の本当の実力は、サイドメニューに表れる。スープをとる店は、つまるところ肉をゆでる店だからだ。**スユク**は薄切りで出てくる。やわらかくてしっとりしていて、冷麺のスープと交互に食べるのにちょうどいい。大ぶりの**平壌マンドゥ**（韓国式の餃子）は具がぎっしり詰まっていて、半皿（6,000ウォン）でも頼めるから、気軽に添えられる。 平壌冷麺、ビビン冷麺、スユク、マンドゥ。この日テーブルに並んだもので、**ハズレはひとつもなかった**。 ## ほかのお客さんの評価は？ 2026年9月時点のNAVER（ネイバー）プレイスの数字。今回の10軒の中で**評価1位**だ。 - ⭐ **来店者評価4.9** · レビュー**2,589件** - 🥇 「**料理がおいしい**」2,444人 - 🏛️ 「**インテリアがおしゃれ**」1,391人、「**店内が広い**」1,114人 - 🙂 「**親切**」937人 - ✨ 「**特別なメニューがある**」841人、「**肉質がいい**」768人 - 📝 レビューでいちばん多く言及されたテーマ：味（2,063件）＞満足度（1,368件）＞サービス（519件） NAVERプレイスのひとこと要約は「**ムルカルビ（スープで煮るカルビ）と冷麺の、調和のとれた出会い**」。つまり、豚カルビやコプチャンチョンゴル（ホルモン鍋）のような肉料理も有名だということだ。次に行くリストにすぐ加えた。 ## メニューと価格 | メニュー | 価格 | | --- | --- | | **平壌冷麺**（看板） | **12,000ウォン** | | **ビビン冷麺** | **12,000ウォン** | | エゴマ油冷麺 | 12,000ウォン | | オンレン・マンドゥクク（マンドゥ入りスープ） | 12,000ウォン | | 平壌マンドゥ（1皿／半皿） | 12,000ウォン／6,000ウォン | | **牛すね肉のスユク**（1皿／半皿） | **32,000ウォン／16,000ウォン** | | テジチェユク（ゆで豚、1皿／半皿） | 22,000ウォン／12,000ウォン | | ハンドン豚カルビ（韓国産豚、300g、看板） | 19,900ウォン | | コプチャンチョンゴル（看板） | 52,000ウォン | 麺の**大盛り（ヤンマニ）は無料**だ。腹ペコの日は、注文するときに必ず伝えよう。 ## 店舗情報 📍 **チョルサンジャン** · ソウル永登浦区キョンインノ77カキル12、1階（文来洞） - 🚇 **アクセス**：1・2号線シンドリム（新道林）駅6番出口から徒歩約8分（約380m）。ムルレ創作村（문래창작촌）の散策とセットにするのにいい。 - 🕐 **営業時間**：11:00〜22:30（ラストオーダー21:30）、平日は**ブレイクタイム15:00〜17:00**、週末はブレイクタイムなし - 💰 **価格**：冷麺12,000ウォン、スユク半皿16,000ウォン - ✅ **設備・サービス**：駐車場、予約、団体利用、子ども用椅子、Wi-Fi、モバイル決済 - 🗺️ **地図**：[NAVERマップ](https://map.naver.com/p/entry/place/2090672889) · [Googleマップ](https://www.google.com/maps/search/?api=1&query=37.511927%2C126.8923209) メニュー価格と営業時間は、2026年9月時点のNAVERプレイスの情報だ。旧正月や秋夕（チュソク）などの連休には変わることがある。行く前に一度チェックしておこう。 ## Jaydenのひとこと評 > 鉄を扱う街のスープは裏切らない。仮説、証明完了。 - **平壌冷麺**：★★★★★ - **ビビン冷麺**：★★★★★ - **スユク・マンドゥ**：★★★★★ - **再訪**：あり。次はムルカルビと冷麺の組み合わせを確かめに行く。 --- # イテウォンのPETRA：中東料理なら1位、フムスひと皿で勝負あり > オリーブオイルがたまったフムスに、ちぎった温かいパンをつけた瞬間、イテウォンの中東料理ランキングが決まった。ノクサピョン駅から5分、スパイスが強すぎない中東料理店PETRA。 _Slug: itaewon-petra-hummus · 2026-09-01_ **ペトラ**（Petra）は、ヨルダンの砂漠のど真ん中で、赤い岩を削って造られた古代都市の名前だ。 イテウォン（梨泰院）に、同じ名前の店がある。ノクサピョン駅から歩いて5分、ビルの2階だ。そしてここで、私のイテウォン中東料理ランキングが決まった。**1位、PETRA**。決め手は**フムス**だった。 **3行まとめ**：中東料理なら、やっぱりここが1位。**フムスを食べれば最高**。温かいパンをちぎって、オリーブオイルのたまったフムスにどっぷりつけた瞬間、勝負あり。スパイスが強すぎないので、中東料理が初めてでも気負わず食べられる。 ## まずはフムス
白い皿に渦巻き状に広げたフムスに、オリーブオイルと刻んだパセリをのせた様子
渦巻きのあいだにたまったオリーブオイル。この一皿で、この店が説明できる。
**フムス**（hummus）は、ゆでたひよこ豆をなめらかにすりつぶして、ゴマのペースト（タヒニ）、レモン汁、オリーブオイル、ニンニクと混ぜた中東の国民的ディップだ。韓国では「홈무스（ホムムス）」とも「후무스（フムス）」とも呼ばれる。 PETRAのフムスは、皿に渦巻き状に広げられて出てくる。溝ごとに黄金色の**オリーブオイル**がたまり、真ん中には刻んだパセリ、上には赤いパプリカパウダー。ひと口すくうと、**驚くほどなめらかでクリーミー**。豆の香ばしさのあとからレモンの爽やかさが追いかけてくるので、いくらすくって食べても、しつこくない。 ## フムスの相棒、パン
ハーブをふってこんがり焼いた平たいパン2枚
ハーブをのせて焼いた平たいパン。ちぎってフムスにどっぷり。
テーブルの上のパンかごとライス料理のフライパン、取り皿
パン、ライス料理、フムス。この組み合わせなら、ふたりでお腹いっぱい。
フムスは、それだけで食べるものじゃない。**パンをちぎって、つけて食べる**ものだ。ハーブをふってこんがり焼いた平たいパンが出てくるので、ひとかけちぎって、オリーブオイルがたまったところを狙い、フムスをたっぷりすくえばいい。外は軽くカリッと、中はもっちりしたパンが、クリーミーなフムスをしっかり受け止めてくれる。 ## お腹を満たすライス料理
黄色く炊いたご飯に、揚げた玉ねぎと刻んだハーブをたっぷりのせたライス料理
香りよく炊き上げた黄色いご飯に、揚げ玉ねぎとハーブ。
フムスとパンで食欲に火がついたら、次はライス料理でお腹を満たす番だ。黄色く炊いたご飯の上に、**カリッと揚げた玉ねぎと刻んだハーブ**がたっぷりのる。スパイスの香りがほんのりするけれど強すぎないので、中東料理が初めての人でも気軽に食べられる。 ## ほかのお客さんの評価は？ 2026年9月時点のNAVER（ネイバー）プレイスの数字だ。 - ⭐ **訪問者評価4.64** · レビュー**705件** - 🥇 「**料理がおいしい**」427人 - ✨ 「**特別なメニューがある**」315人 - 🙂 「**接客が親切**」152人、「**量が多い**」117人、「**食材が新鮮**」116人 - 📝 レビューでいちばん多く触れられたテーマ：味（320件）＞満足度（219件）＞サービス（90件） NAVERプレイスの一行まとめは「**スパイスが気にならない韓国風の中東料理**」。私が感じたとおりだ。中東料理デビューに、これ以上の店はない。 ## メニューと価格 | メニュー | 価格 | | --- | --- | | **フムス** | **9,000ウォン** | | ババガヌーシュ（焼きナスのディップ） | 9,000ウォン | | ラバネ（ヨーグルトチーズのディップ） | 9,000ウォン | | ファラフェル | 8,000〜12,000ウォン | | ミジャ（미자） | 11,000ウォン | | タブーリサラダ／オリーブサラダ | 9,000ウォン | | タヒニサラダ | 12,000ウォン | | ピタ（パン） | 2,000〜4,000ウォン | | ジャスミンライス／サフランライス／クスクス | 5,000ウォン | ディップ（フムス、ババガヌーシュ、ラバネ）を2、3品頼んでパンを添えれば、みんなでシェアする中東式のごちそうになる。 ## 店舗情報 📍 **PETRA** · 서울 용산구 녹사평대로40길 33、2階 - 🚇 **アクセス**：6号線ノクサピョン駅1番出口から徒歩約5分（約180m）、イテウォン駅1番出口から徒歩約9分 - 🕐 **営業時間**：毎日11:30〜21:00 - 💰 **価格**：ディップ9,000ウォン、ライス・クスクス5,000ウォン、パン2,000ウォンから - ✅ **便利情報**：Wi-Fiあり - 🗺️ **地図**：[NAVERマップ](https://map.naver.com/p/entry/place/11701020) · [Googleマップ](https://www.google.com/maps/search/?api=1&query=37.5346857%2C126.9877129) イテウォンでもう一食探しているなら、坂の上のヘバンチョン（解放村）にある[ザ・バック・フードトラック](/ja/posts/haebangchon-the-back-food-truck-burger)もある。 メニュー価格と営業時間は、2026年9月時点のNAVERプレイスの情報だ。行く前に一度チェックしておこう。 ## Jaydenのひとこと評 > パンひとかけ、フムスひとさじ。砂漠の都市の名を冠した店で、うるおいを教わった。 - **フムス**：★★★★★ - **パン**：★★★★★ - **リピート**：あり。次はババガヌーシュとファラフェルまで、フルコースで。 --- # AIは私のPMP合格を助けなかった。学び方を変えただけだ > AIをただの知識検索ツールではなく、問いを引き出し、思考力を鍛えるパートナーとして活用して築いた、PMP合格の裏にある学習フィードバックシステムと振り返りの記録。 _Slug: ai-changed-how-i-learn · 2026-07-20_ PMP（Project Management Professional）試験に合格したと報告したとき、いちばん多く受けた質問は、意外なほどシンプルだった。 > **「どんなプロンプトを使ったんですか？」** そう聞かれるたびに、軽くほほ笑むしかなかった。聞いてくる人たちが核心を見落としていると、わかっていたからだ。私を合格に導いたのは、特定のプロンプトの文面ではなかった。私が設計し、くり返し回してきた「**学習ワークフロー（Workflow）**」そのものだった。 この気づきは、PMPの試験勉強だけにとどまらない。これから私が学び、身につけていくべきあらゆる分野の勉強法を、すっかり変えてしまった。この記事は、未来の私が新しい挑戦を始めるときに、もう一度取り出して読み、実践するための、自分だけの学習システムの記録だ。 --- ## ほとんどの人は、AIを「Google」として使う 私も最初は、同じ失敗をくり返すところだった。 1. 問題を解いていて行き詰まったら、AIに質問する。 2. AIがすぐに出してくれる正解と解説を読む。 3. わかったつもりになって、次の問題へ進む。 このプロセスは、とても効率的で生産的に感じられる。でも残念ながら、こうして得た知識は頭に長くとどまらない。答えが簡単に手に入るほど、脳は覚えようとする努力をやめてしまうからだ。 あるとき気づいた。**AIは答えを教えてくれるときよりも、自分の考えの穴を突く、よりよい問いを投げかけさせてくれるときにこそ、本当の価値を発揮する**。正解の自販機ではなく、思考の相棒（Thinking Partner）として向き合うべきなのだ。 --- ## 私がつくった学習フィードバックループ（Learning Feedback Loop） 正解を探すかわりに、ミスを知識に変える頑丈なフィードバックシステムを築いた。 ``` [質問 & 問題演習] ↓ [自力で挑戦] ↓ [誤答の発見] ↓ [AIの解説と多角的な分析] ↓ [深い内省] ↓ [自分専用の誤答ノート] ↓ [フラッシュカードに登録] ↓ [解き直し] ``` ただたくさん解けばいいわけではない。間違えたときにシステムが動き出し、その誤答を分析して自分の知識として定着させる。その経路をきちんとたどることが大事なのだ。 --- ## AIを思考のパートナーとして活用した5つの原則 未来の私が勉強するときに必ず守るべき五つの原則を、ここにまとめておく。 ### 1. すべての誤答の「理由」を分解せよ たいていの人は「なぜAが正解なのか？」と聞く。でも、本当の学びは残りの選択肢のほうにある。私はAIに、よくこう質問していた。 > *「この問題でAが正解なのはわかった。でも、なぜB、C、Dは不正解にしかならないの？　それぞれ、どんな状況や前提がずれているのか、具体的に比較して」* 正しい選択肢をひとつ理解するよりも、間違った選択肢3つがなぜ誤りなのか、その要素を分解していくほうがずっと役に立つ。この習慣のおかげで、出題機関（PMI）ならではの価値観と出題意図を、はるかに深く理解できた。 ### 2. メンタルモデルの境界を比較せよ たとえば、予測型（Predictive）、アジャイル（Agile）、ハイブリッド（Hybrid）のどの手法をとるか迷ったとき、単に「ここではどの手法が正しい？」とは聞かなかった。 > *「予測型、アジャイル、ハイブリッドの三つのアプローチがある。この状況でそれぞれの手法に固執したら、起こりうるいちばん致命的な失敗シナリオは何？」* それぞれのモデルの長所よりも、「**どこで失敗し、限界をさらけ出すのか（Failure modes）**」を比べたとき、ようやく各メンタルモデルのはっきりとした境界線が見えてきた。 ### 3. AIに自分を批判させ、攻撃させよ ときには、私の論理に真っ向から反論してくれとAIに頼んだ。メタ認知（Metacognition）を強制的に働かせる、すばらしい方法だ。 ```markdown ロールプレイの設定： 「あなたは厳格で疑り深いPMPの主任講師だ。 私がいま導き出した結論について、なぜ私の考えが間違っているのか、論理的な盲点を見つけ出し、 私を説得してみて」 ``` AIの鋭い反論に応えようと考えを整理し直し、防御の論理を組み立てていくうちに、頭のなかの生半可な知識がしっかりと構造化されていった。 ### 4. ミスを再利用できる資産（Asset）に変えよ 間違えた問題は、一度きりの経験として流してしまわず、資産に変えた。 * **フラッシュカード**（Ankiなど）にして、定期的な復習サイクルを設定する * 単なる要約ではなく、「**なぜ自分はこの誤答に惹かれたのか**」を分析するノートを書く * ほかの人に説明できるくらいの、**短い一文の要約を書く** 誤答を資産に変えるプロセスをくり返すうちに、最初はいちばん弱かった分野が、試験の終盤にはいちばん自信のある得意分野に変わっていた。 ### 5. 誤りのパターンを俯瞰して把握せよ AIの強みは、個々の問題の答えを教えてくれることではない。私が集めた誤答データのなかから「**パターン**」を抽出してくれることにある。 間違えた問題と誤答ノートをまとめてAIに入力し、分析を頼んだ。 * くり返される論理の飛躍 * 概念そのものを誤って理解している部分 * 特定の状況（例：コンフリクト・マネジメントなど）で判断を誤る傾向 出題範囲全体をやみくもに読み返す非効率なやり方のかわりに、AIが指摘してくれた思考の弱点を集中的に叩くことで、勉強の密度を最大限に高めることができた。 --- ## 合格したあとに残った思い 試験のあとLinkedInに投稿した記事は、ありがたいことに21,000回以上のインプレッションを記録し、たくさんの関心を集めた。けれど、実際に私のもとに届いたフィードバックには、物足りなさが残った。ほとんどが相変わらず「どんなプロンプトを使ったのか」「もっといい裏ワザはないか」ばかりに注目していたのだ。 人はいつも、目に見える近道（Shortcuts）を探す。でも持続的な成長は、いいプロンプトを集めることからは生まれない。**自分のミスにまっすぐ向き合い、それを改善していける頑丈な学習システムを築くこと**から始まるのだ。 プロンプトは変わりうるし、AIモデルも進化し続ける。でも、知識を身につけ、消化していくフィードバックループは、変わることのない本質だ。 ## 未来の自分のためのまとめ（Key Takeaways） * AIを知識の自販機ではなく、**思考のトレーニングパートナー**として扱え。 * 正解を当てることより、**誤答の理由を徹底的に分解すること**が先だ。 * どんなミスも放置せず、**あとで取り出して見返せる学習資産**として構造化せよ。 * 一時的なモチベーションは薄れていく。最後に支えてくれるのは**フィードバックシステム**だ。 * 問いの質が、そのまま成長の限界を決める。最高のプロンプトは、いつも「**なぜ自分は間違えたのか？**」という問いだった。 このシステムはPMPを超えて、これから私が向き合うプロジェクトマネジメント、語学、プロダクトづくり、文章を書くことなど、あらゆる分野の骨組みになるはずだ。次に何か新しいことを学ぶときは、まずこのフィードバックループを回そう。 --- # AIを使ってひとりでプロダクトをつくるプロセス：アイデアからリリースまで > AIをリサーチ、企画、開発、テストのパートナーにして、ひとりでつくるプロダクトをアイデアからMVP、そして実際のリリースまで進める現実的なプロセスと原則をまとめた。 _Slug: building-products-alone-with-ai · 2026-07-15_ 以前は、プロダクトひとつをつくるのに、それぞれ別の役割を担う何人もの人が必要だった。いまはAIのおかげで、ひとりでもユーザー調査、企画、デザイン、開発、テスト、ドキュメント作成までをすばやく行き来できる。だからといって、AIがチーム全体の代わりになってくれるわけではない。むしろ、ひとりでつくる人の肩には、より多くの判断と責任がのしかかってくる。 私が考える**AIを活用したひとりでのプロダクト開発**の核心は、コードを速く生成することにはない。解くべき問題を絞り込み、余計な作業を減らし、実際のユーザーに届くまでの時間を縮めることにある。この記事は、アイデアを思いついた瞬間からMVPを公開してフィードバックをもらうまでに、私がたどっているプロセスをまとめた記録だ。 AIはスピードを上げてはくれるが、方向までは決めてくれない。何をつくるのか、誰のためにつくるのか、いつやめるのかは、人間が決めなければならない。 ## AIは共同創業者ではなく、スピードを上げるための道具だ AIに「いいサービスのアイデアを教えて」と聞けば、それらしいリストがすぐに手に入る。問題は、そのリストが私の経験も、私が実際にアプローチできるユーザーも、私が負担できるコストも知らないことだ。 だから私は、AIを共同創業者のようには扱わない。そのかわり、役割のはっきりした何人ものアシスタントとして使っている。 - **リサーチアシスタント**：市場と競合プロダクトをざっと見渡す。 - **企画アシスタント**：要件を整理し、抜けている条件について質問する。 - **開発アシスタント**：小さな機能を実装し、コードを説明する。 - **テストアシスタント**：失敗しうるケースとテスト項目を洗い出す。 - **編集アシスタント**：ランディングページや案内文、ドキュメントを整える。 最終的な決定権は、いつも自分の手元に残しておく。この線引きがないと、生成のスピードは上がっても、プロダクトはいとも簡単に見当違いの方向へ大きくなっていく。 ## 1. 解決する問題を一文で定義する プロダクトをつくる前に、まず次の文を完成させる。 > **[どんな人]が[どんな状況]で抱えている[具体的な問題]を、[どんな方法]で減らす。** たとえば「AIのスケジュール管理アプリをつくる」は、プロダクトの説明であって問題の定義ではない。「複数のプロジェクトを同時に回している個人事業主が、今日必ずやるべきことを5分以内に決められるよう手助けする」という文なら、ユーザーと状況、そして結果が見えてくる。 このときAIには、アイデアを出してもらうよりも、この文の穴を突いてもらうように頼む。 - この問題は実際によく起きているか？ - ユーザーはいま、どんな方法で解決しているか？ - お金や時間をかけてでも変えたいほど不便なのか？ - もっと絞り込めるユーザーは誰か？ - プロダクトがなくても検証できる仮説は何か？ いい出発点とは、答えがたくさんあるアイデアではなく、確かめるべき問いがはっきりしているアイデアだ。 ## 2. AIで調べ、人に確かめる 初期の調査では、AIはとにかく速い。競合プロダクトをタイプ別に分けたり、想定ユーザーを整理したり、インタビューの質問案をつくったりするのに役立つ。ただし、生成された要約を市場の事実として受け取ってはいけない。 私は調査結果を3つの層に分けている。 1. **AIが提案した仮説**：まだ確認されていないアイデア 2. **自分で確認した資料**：プロダクトページ、価格、レビュー、公開ドキュメント 3. **ユーザーが語った経験**：インタビュー、観察、実際の行動 プロダクトの方向性は、3つ目の層に近づくほど信頼できる。できれば、潜在ユーザー5人に同じ問題について聞いてみる。「この機能を使いますか？」よりも、「最近この問題をどうやって解決しましたか？」のほうがいい質問だ。未来の意向よりも、過去の行動のほうが強い証拠になるからだ。 ## 3. 1ページのプロダクト仕様書をつくる 調査が終わったら、長い企画書のかわりに1ページだけのプロダクト仕様書を書く。そこに載せるのは次の項目だけだ。 | 項目 | 書くべき内容 | |---|---| | ユーザー | 今回のバージョンで集中する1種類のユーザー | | 問題 | くり返し起きている具体的な不便 | | 約束 | 使ったあとに変わるひとつの結果 | | コアフロー | ユーザーが最初から最後までたどる行動 | | スコープ外 | 今回はつくらない機能 | | 成功基準 | リリース後に確認する行動または数字 | | リスク | 個人情報、コスト、精度、運用の負担 | この仕様書をAIにレビューさせると、互いに矛盾する条件や抜けている例外をすばやく見つけられる。特に大事なのが、**スコープ外**をはっきり書いておくことだ。ひとりでつくるプロダクトは、機能不足よりも、スコープの膨らみすぎで止まることのほうが多い。 アイデアが調査、設計、実装、テストを経てリリースされる、AIを活用したひとりでのプロダクト開発の流れ *AIが各段階をすばやくつないでくれても、次の段階に進むかどうかを決めるのは、プロダクトをつくる私自身だ。* ## 4. MVPでは最短のユーザーフローだけをつくる MVPは完成度の低いプロダクトではなく、**いちばん重要な仮説を、いちばん少ない機能で確かめるプロダクト**だ。私は最初のバージョンのフローを、たいてい4つのステップに絞っている。 1. ユーザーがやって来る。 2. 必要な情報を入力する。 3. プロダクトが核となる結果を生み出す。 4. ユーザーが結果を保存するか、次の行動に移る。 アカウント設定、ダッシュボード、通知、決済、管理画面は、核となる仮説に直接関係しないなら後回しにする。まずはクリックできる画面や、シンプルな手作業のサービスでフローを検証してもいい。コードを一行も書かずに、ユーザーのために結果を手づくりしたほうが速いケースも多い。 AIを使うと、機能を足すのが簡単になる。だからこそ、削るための基準をもっと厳しくしなければならない。「つくれるか？」ではなく、「この機能なしでは仮説を検証できないのか？」を問う。 ## 5. AIと開発するときは小さな単位で任せる 「このサービスを全部つくって」と頼めば、大量のコードがすぐにできあがる。でも同時に、レビューしにくいシステムまでできあがってしまう。私は作業を、画面ひとつ、ユーザーの行動ひとつ、データの流れひとつといった小さな単位に分けている。 AIに開発作業を頼むときは、次の4つをセットで渡す。 ```text 目標：ユーザーがメールアドレスでログインできるようにする。 現在の状態：使っているフレームワークと関連ファイルを説明する。 制約：既存の構成、セキュリティのルール、変更してはいけない範囲を書く。 完了条件：成功・失敗のフローと、実行すべきテストを定義する。 ``` コードが生成されても、すぐに次の機能には進まない。変更されたファイルを読み、実際に動かし、失敗したときの経路を確認する。理解できないコードは、自分では保守できないコードだ。AIがきちんと説明できなかったり、テストが不安定だったりしたら、実装をもっと小さな単位に戻す。 ### 私が守っている開発の手順 1. いまの構成と目標をAIに説明する。 2. まずは実装計画と、変更するファイルの一覧だけを出してもらう。 3. 一度にひとつずつ、小さな変更を適用する。 4. 型チェック、リント、テスト、ビルドを実行する。 5. ブラウザで実際のユーザーフローを確認する。 6. 変更した理由と、残っているリスクを記録する。 この手順を守れば、AIが書いたコードを手で書き直す時間よりも、レビューと判断により多くの時間を使えるようになる。 ## 6. テストとセキュリティはAIに丸投げしない AIは、テストケースを提案したり、セキュリティ上の問題を見つけたりするのを手伝ってくれる。しかし、「問題ありません」という答えをお墨付きとして受け取ってはいけない。特に認証、決済、個人情報、ファイルアップロード、外部APIが絡むなら、人間が自分の目で確認しなければならない。 リリース前には、最低限次の点をチェックする。 - 正常系だけでなく、空の入力、不正な値、重複したリクエストも試す。 - シークレットキーや個人情報が、ブラウザやログに露出していないか確認する。 - ユーザーがほかのユーザーのデータにアクセスできないことを確認する。 - AI機能が間違えたり応答しなかったりしたときの画面を用意しておく。 - 想定より利用量が増えたときに備えて、コストの上限と利用制限があるか確認する。 - モバイル画面、遅いネットワーク、アクセシビリティの基本的な動作を確認する。 ユーザーが入力した機密性の高い情報や、会社の非公開コードを外部のAIサービスに送る前には、データの保管ポリシーと利用権限を必ず確認しなければならない。 ## 7. 小さくリリースして、実際の反応を記録する リリースは最後のステップではなく、いちばん正確な調査が始まるタイミングだ。最初から大勢に知らせるより、その問題を実際に抱えている小さなユーザーグループに公開する。 最初のリリースでは、ページビューよりも次のような行動を見る。 - ユーザーが説明なしでコアフローを最後までこなせるか？ - 結果をもう一度使ったり、ほかの人に共有したりしているか？ - どのステップで止まっているか？ - プロダクトがなくなったら残念だと言ってくれるか？ - 時間やお金を払う意思が、行動になって表れているか？ インタビューのメモやログをまとめて、くり返し出てくるパターンを探すのにはAIが使える。ただし、ユーザーごとに異なる意見を無理にひとつの結論にまとめることはしない。何を直すかは、プロダクトの約束にいちばん近い問題から選ぶ。 ## ひとりでプロダクトをつくる7日間の実行ループ 小さな実験なら、次のような1週間単位で回せる。 | 日程 | やること | 成果物 | |---|---|---| | 1日目 | 問題とユーザーを絞り込む | 一文の問題定義 | | 2日目 | 資料調査とユーザーとの対話 | 核となる仮説3つ | | 3日目 | プロダクトのフローとスコープ外を決める | 1ページの仕様書 | | 4〜5日目 | AIとコアフローを実装する | 動くMVP | | 6日目 | テストとセキュリティのチェック | リリース用チェックリスト | | 7日目 | 少数のユーザーに公開する | 観察記録と次の判断 | 1週間で良いプロダクトが完成するわけではない。そのかわり、つくり続ける価値があるかどうかを判断できるだけの証拠は手に入る。このスピードこそ、AIを使ういちばん現実的な理由だ。 ## AIが得意なことと、自分でやるべきこと ### AIに積極的に任せられること - 資料の一次分類と要約 - 質問リストやドキュメントの下書き作成 - くり返しの多いコードやテストのひな形の生成 - エラーメッセージの説明と、デバッグの仮説出し - 文言のバリエーションや翻訳の下書きの生成 - 会議やユーザーインタビューのメモの整理 ### 最後まで自分で責任を持つべきこと - どの問題を解決するかを選ぶこと - ユーザーの言葉を文脈の中で解釈すること - プロダクトの品質とセキュリティの基準を決めること - 生成されたコードや情報が正しいかを検証すること - 何を捨てて、いつリリースするかを決めること - 失敗のコストと、ユーザーに及ぶ影響に責任を持つこと ## よくある質問 ### 開発者でなくても、AIでプロダクトはつくれるのか？ シンプルなプロトタイプや手作業のサービスなら可能だ。ただ、ユーザーのデータや決済が絡む本番のプロダクトとなると、システムの構造、セキュリティ、運用を理解している必要がある。わからない部分をAIの確信に頼って覆い隠すより、スコープを絞るか、専門家にレビューしてもらうほうが安全だ。 ### どのAIツールから選べばいいのか？ ツールより先に、作業を決めるのがいい。調査、ドキュメント作成、デザイン、コーディング、テストのうち、いちばん時間がかかっているステップをひとつ選び、それに合ったツールをひとつ使うところから始める。ツールをいくつもつなぐより、くり返し使える仕事の進め方をつくるほうが先だ。 ### AIが書いたコードはそのまま使っていいのか？ そのままデプロイしてはいけない。コードの動作、依存関係、ライセンス、セキュリティ、例外処理をレビューし、プロジェクトのテストとビルドを通さなければならない。説明できないコードは、プロダクトの負債になる。 ### ひとりでつくるとき、いちばん大事な指標は何か？ 初期は、登録者数よりも、核となる問題を実際に解決できたユーザーの数が大事だ。プロダクトの核となる行動を最後までやり遂げた人、また戻ってきた人、結果のためにお金を払った人を、まず見る。 ## 結局、プロダクトをつくるのは人間だ AIは、ひとりでプロダクトをつくる人の手を速くしてくれる。調査と実装のあいだの距離を縮め、慣れない役割にも踏み出せるように助けてくれる。でも、プロダクトの方向性も、ユーザーへの理解も、リリースする勇気も、自動ではつくってくれない。 ひとりでつくる良いプロダクトとは、AI機能をいちばんたくさん使ったプロダクトではない。**小さな問題を正確に選び、実際のユーザーにすばやく届け、学んだことを次のバージョンに反映したプロダクト**だ。 私は[人生をひとつのプロジェクトとして見ている](/ja/posts/built-slowly-updated-daily)。プロダクトづくりも同じだ。完璧な計画を待つより、小さなバージョンを公開し、結果を記録し、次の判断を下す。AIはそのプロジェクトを代わりに担う存在ではなく、より短いサイクルで実行できるようにしてくれる道具だ。 --- # AIが書いたコードの品質を疑う方法：個人開発者のための8つの検証原則 > AIコーディングツールでAttractiveWebAIやShopifyアプリなどを開発するなかで経験した10の失敗と、動いているように見える「UIの錯覚」を乗り越えてコード品質を守るための8つの現実的な原則を共有する。 _Slug: principles-of-maintaining-code-quality-with-ai · 2026-07-13_ #### もっともらしい画面が生んだ錯覚 Shopifyのメンバーシップアプリで最初のデモビルドが成功したとき、私は興奮を隠せなかった。画面にはすっきりしたダッシュボードが表示され、設定メニューのトグルボタンはなめらかに動き、ポイント付与のルールを入力するフォームも完璧に見えた。マウスをクリックするたびに、画面はきびきびと反応した。AIコーディングツールに何度か指示を打ち込んでから、わずか2日で手に入れた成果だった。このペースなら、来週にでもアプリストアに公開できそうな気がした。 でも、喜びは長くは続かなかった。テストアカウントでストアから実際に決済を進め、顧客ランクを上げようとしたところ、アプリはまったく反応しなかった。コードを掘り下げて調べてみて、ようやく厳しい現実を突きつけられた。画面に表示されていたもっともらしい数字は、すべてAIが勝手に埋め込んだMock Data（ダミーデータ）で、肝心のお金を扱う決済APIも、ポイント付与のWebhookも、自動割引のトリガーも、一行たりとも書かれていなかったのだ。外側の殻だけがあって、中身はからっぽだった。 私はプロのソフトウェアエンジニアではない。ITプロジェクトマネージャー（PM）として働きながら、必要なプロダクトをAIの力を借りて自分でつくり、デプロイしている個人のつくり手に近い。Webサイト分析SaaSのAttractiveWebAI、Shopifyのメンバーシップアプリ、そしてmacOSのウィンドウプレビュー用ユーティリティまで、いくつものプロダクトを開発するなかで、Gemini、Claude、Codexといったツールをあらゆる場面で使い倒してきた。 最初のうちは、ほしい機能をざっくり説明するだけで、ちゃんと動くコードがあっという間に出てくるスピードに酔っていた。ところがプロジェクトの規模が大きくなり、機能同士が絡み合いはじめると、画面の裏に隠れていた欠陥がいっせいに頭をもたげてきた。 --- #### AIが隠していた10の負債 デプロイの段階を経るなかで、痛い思いをしながら書き留めてきた失敗のリストは、思っていたより長く、具体的だった。 1. **DBへの保存漏れ**：フロントエンドのフォームで「保存」ボタンを押すと、画面には成功メッセージが出る。なのに肝心のSupabaseのデータベースには何も書き込まれず、データはメモリの中をさまよったあげく消えていた。 2. **消えたAPI接続**：フロントエンドUIのかっこいいボタンや入力欄は完成していたのに、バックエンドのAPIエンドポイントと通信するコードが抜けていて、実際のサービスは動かなかった。 3. **ダミーデータの放置**：開発の都合で一時的に入れたMock Dataやテスト用のハードコード値が、本番の運用モードでもそのまま使われていた。 4. **同じコードの重複生成**：AIが既存プロジェクトの全体構造を覚えていられず、すでにあるユーティリティ関数やコンポーネントを、名前だけ少し変えて、3つも4つも重複してつくっていた。 5. **回帰（リグレッション）エラー**：ある箇所のバグを直そうとコードを修正すると、それまで問題なく動いていたまったく別のページの機能が壊れる。そんなことがくり返された。 6. **ビルド成功の罠**：`npm run build`もTypeScriptの型チェックも完璧に通ったのに、ランタイムで特定の条件になると、ブラウザが真っ白な画面しか出さなくなる致命的なエラーが起きた。 7. **`console.log`だけが残った報告**：AIは機能の実装を終えたと堂々と答えたが、コードを開いてみると、中身のかわりに`console.log("TODO: 実装予定")`というコメントだけがぽつんと残されていた。 8. **データベーススキーマの欠落**：ローカル開発環境のSupabaseテストアカウントでは問題なく動いていた機能を、本番用のSupabaseアカウントに移したときのこと。コードと環境変数は切り替えたのに、SQLのテーブルとトリガーのスキーマを移行していなかったせいで、サービス全体が止まった。 9. **コアロジックの省略**：Shopifyアプリをデプロイする過程で、画面デザインは仕上がっていた。しかし肝心のBilling APIとの連携と、自動割引ポリシーを呼び出すロジックがつながっておらず、実際の収益モデルを検証できなかった。 10. **システム権限の認識エラー**：macOSのウィンドウプレビュー用ユーティリティを開発していたとき、OSの設定画面ではアクセシビリティと画面収録の権限がオンになっているように見えても、実際のランタイムのコードではその権限の状態を検知できず、アプリが固まってしまう。そんなデバイスレベルの例外が頻発した。 こうした失敗の後始末に追われて夜を明かすうちに、あることにハッと気づかされた。AIコーディングの本当のボトルネックは、コードを書くという行為そのものではなかった。**AIが吐き出したコードを検証し、それが「完全に完了した」ことを人間の目で証明するプロセス**こそが核心だったのだ。ここを放置すれば、プロダクトは動いているふりをする技術的負債の巨大な沼に変わってしまう。 この試行錯誤をくぐり抜けるなかで私が確立した、8つのコード品質検証の原則を共有する。 --- #### 原則1. 頼む前に、まず完了条件（Definition of Done）を書く AIに「ログイン機能をつくって」とあいまいに頼むと、AIは勝手に楽な方法を選んで、とりあえず動くだけのコードを書く。私は機能を頼む前に、必ず検証すべきチェックリストをあらかじめ書いて、依頼文に含めている。 ```markdown [完了条件] 1. ユーザーがGoogle OAuthアカウントでログインできるか？ 2. ログインセッションは、リロードやブラウザの再起動後も維持されるか？ 3. ログアウトボタンを押すとセッションが削除され、トップページにリダイレクトされるか？ 4. ログインしていないユーザーがAPIを直接呼び出したとき、401 Unauthorizedエラーを返すか？ 5. ログインしたユーザーは、自分のデータだけを閲覧・修正できるか？ 6. パスワードや機密性の高いトークンが、ローカルストレージに平文で残っていないか？ ``` こうして明確な制約とテストシナリオを渡すと、AIは例外処理のコードやセキュリティのロジックを省かず、最初からきっちり骨組みを埋めてくれる。 #### 原則2. AIの完了報告を、決してそのまま信じない AIが「ご依頼の機能を完璧に実装しました」と言うときこそ、いちばん危ない。私はAIの報告を受けたらすぐに、その成果物を確かめるため、いつも次の質問を投げて答えを求めている。 * 変更されたファイル、新しく作成されたファイルの全リスト * 各ファイルで実際に修正された主要なコード箇所と、その理由 * 一時的なテストのために残したMock Dataやハードコードされた値があるかどうか * コード内に含まれる`TODO`コメントや`console.log`の位置 * まだ実装できていない部分や、環境の制約で残した技術的な限界 この質問を投げるだけで、AIは「実はこれこれの部分は仮のデータで処理しています」と抜けていた部分を遅ればせながら白状したり、自分から未完成のコードを補強したりする。 #### 原則3. ビルドの成功と機能の成功を厳密に区別する コンパイラがエラーを出さないからといって、ビジネスロジックがうまくいっているわけではない。ターミナルに緑色の成功メッセージが出たあとも、必ず手作業で次の項目をひとつずつ検証する。 * **状態の保持**：フォームに入力して保存したあと、ブラウザを強制的にリロードしても、データがデータベースから正しく読み込み直されるかを確認する。 * **限界値の入力**：空の値のまま送信する、おかしな文字を入力する、ボタンを連打する、といった操作を立て続けに行い、システムが落ちないかを見る。 * **権限の分離**：ログインしていない状態や、ほかのユーザーのアカウントトークンを真似た状態で、非公開ページやAPIエンドポイントへのアクセスを試してみる。 * **ログの確認**：正常に動いている画面の裏で、ブラウザのコンソールやサーバーログに404エラーや`unhandled rejection`の警告が隠れていないかを観察する。 #### 原則4. 作業の単位をできるだけ小さく分ける 一度に「ダッシュボードページと分析データの連携をまとめてやって」と大きなかたまりで頼むと、AIは高い確率で内部構造をめちゃくちゃに混ぜたり、ロジックの一部を抜かしたりする。面倒でも、ステップは徹底的に分ける。 1. **データスキーマの設計**：データベースのテーブル構造とリレーション設定のSQLを書いて反映する。 2. **APIハンドラーの作成**：データを取得・保存するバックエンドのAPIエンドポイントを先につくり、Postmanなどで単体テストする。 3. **UIのバインディング**：画面のコンポーネントをつくり、先ほどつくったAPIにつなぐ。 4. **例外処理の追加**：ネットワークの切断、入力エラー、エラーレスポンスといった状況での案内メッセージを入れる。 5. **プロダクション検証**：ローカル環境を離れ、stagingまたはデプロイ先のURLで、実際に動くかどうかを最終確認する。 #### 原則5. コードを書くAIとレビューするAIを分ける ひとつのチャットセッションで同じAIモデルにコードを書かせ続け、そのままレビューまでさせると、自分が書いたコードの論理的な誤りが見えなくなる認知バイアスに陥る。 私は機能を実装し終えたら、そのコードをまったく新しい会話セッションか、別のモデル（例：Claudeで書いたならGeminiでレビュー）に渡して、次のようなプロンプトを与える。 > 「このコードは、ある機能のために書かれたものです。あなたは非常に厳しいシニアバックエンドエンジニアであり、QAのスペシャリストです。このコードのセキュリティ脆弱性、エッジケースでエラーが起きる可能性、パフォーマンスの非効率、構造的な改善点を、遠慮なく厳しくレビューしてください。」 このやり方なら、ひとりで働いていても、とても優秀なコードレビューのパートナーをそばに置いているのと同じ効果が得られる。 #### 原則6. 機能ごとの実装状況をマトリクスで管理する 「ダッシュボードページ、完成しました」というひと言には、誤解の余地がありすぎる。企画者、デザイナー、開発者としての自分をひとりで全部抱える個人開発者には、もっと明確な基準が必要だ。私はメモ帳やNotionに、機能ごとに次の状態を細かく分けてチェックしている。 * [ ] **未実装（Unimplemented）**：企画だけが存在する * [ ] **UIレイアウト完了（UI Only）**：画面の見た目だけができている * [ ] **仮データ接続（Mock Data）**：ローカルのダミーデータで、動いているふりをしているだけ * [ ] **バックエンドAPI接続完了（API Connected）**：API通信はできる * [ ] **DB永続化の確認（DB Persisted）**：実際のDBへの書き込みと読み込みが保証されている * [ ] **例外・エッジケースのテスト完了（QA Verified）**：失敗時のテストを通過 * [ ] **本番環境での検証完了（Prod Verified）**：本番サーバーへのデプロイ後の検証まで終了 この段階を踏まずに、目に見える画面だけで機能を完了扱いにしてしまうと、あとでどこが偽物でどこが本物なのか、自分でも見分けがつかない混乱に陥ることになる。 #### 原則7. コードを修正する前に、まず既存の文脈を理解させる 既存プロジェクトのソースコードをいきなり渡して「ここにこれを追加して」と言うと、AIは既存のコーディングパターンや設計原則を無視して、ad-hoc（その場しのぎ）な汚いコードを継ぎ足しがちだ。修正を頼む前に、まず既存の構造の文脈を把握させなければならない。 > 「このファイルのコードを修正する予定です。変更をお願いする前に、まずこのファイルの現在の構造とデータの流れ、そして実装方法の意図を説明してください。どの関数が影響を受ける可能性があるかも整理してください。」 AIが既存のコードを正確に読み解き、分析結果を出してきたのを確認してから、はじめて「では、その意図とパターンに沿って、最小限の変更で機能を実装して」と頼む。このステップひとつだけで、コードの一貫性は見違えるほど良くなる。 #### 原則8. 負債を抱えるのはいい。ただし隠さない 開発をしていると、スケジュールやリソースの限界から、どうしても近道を選ばざるを得ないときがある。仮のデータをハードコードしたり、セキュリティの検証をいったん後回しにしたりといった具合だ。このとき大事なのは、その「負債」をコードの中にこっそり埋めておかないことだ。 私は技術的負債のリストを、プロジェクトのルートフォルダに`tech-debt.md`というファイルで明記しておき、その場しのぎの手を使うたびにすぐ記録している。 ```markdown ## 現在のプロジェクトの技術的負債リスト * [AttractiveWebAI] 分析チャートでまだ仮のMock Dataを使用中（本番デプロイ前にBigQuery APIパイプラインとの連携が必須） * [Shopifyメンバーシップ] 新規会員登録特典の決済処理で、割引検証Webhookの受信部が欠落（本番デプロイ前にセキュリティチェック必須） * [共通] ユーザーセッションの期限切れで例外が発生したときのログアウト処理が不十分 * [macOSユーティリティ] システムのアクセシビリティ権限の取得確認用に、ハードコードされた待機時間（3秒）がある -> イベント駆動のトリガーに変更が必要 ``` 汚いコードを書いたという事実よりも怖いのは、どこに汚いコードを残したのかを忘れてしまうことだ。負債の大きさを目に見える形で管理しておけば、次の開発サイクルで何から改善すべきかがはっきりわかる。 --- #### 本当に完成したプロダクトのために AIを使った開発は、開発を「軽い行為」のように感じさせる。プロンプト欄に何度か質問を投げるだけで何百行ものコードが埋まり、ビルドが完了していくのを見ていると、自分がとてつもなく大きなプロダクトをあっという間にコントロールしているような錯覚に陥る。 でも、本当に完成度の高いプロダクトを決めるのは、書かれたコードの量ではない。捨てた仮のコードの量と、確認した例外ケースの数だ。動かない機能を動いているように見せかけただけの、殻だけのプロダクトは、最初のユーザーが入ってきた瞬間に砂の城のように崩れる。 AIは優秀な伴走者であり、タイピングの秘書だ。しかし、プロダクトの完了ラインを引き、品質を保証する最後の砦は、いまも企画し検証する人間の役目だ。華やかな画面の裏に隠れた動作ひとつ、データ一行を厳しい目で分解して確かめる執念こそが、AI時代に個人のつくり手が身につけるべき本当の開発力なのかもしれない。 --- # PMP合格体験記 第2部：試験当日の時間配分と、合格のための最後のアドバイス > ソウル・ムギョロのPearson VUEセンターで、韓国語でPMPを受けた日の記録。予約メールの内容、到着時間と身分証明書のルール、最初の60問に80分、10分の休憩、直前の復習法までまとめました。 _Slug: pmp-pass-review-part-2 · 2026-07-05_ [第1部](/ja/posts/pmp-pass-review-part-1)では、約7週間の勉強の過程と、実際にかかった費用、Study Hallの点数をまとめました。 第2部では、試験会場に入った瞬間からPASSの結果シートを受け取るまでを、時間の流れに沿って記録します。勉強しているときは気づきませんでしたが、実際に受けてみると、**知識と同じくらい、体力、時間管理、休憩の使い方が大事でした**。 **3行まとめ**：私は2026年7月3日の午前10時15分、ソウル・ムギョロ（무교로）のPearson VUEセンターで、PMPを韓国語で受けました。最初の60問に80分かけて動揺しましたが、休憩のあとで戦略を変え、最後のセッションでは少し時間が余りました。当日は30分早く到着し、予約名とまったく同じ氏名の、政府発行の身分証明書の原本を必ず持っていってください。 **私が受けた試験と今の試験は、構成が違います**。 - 私が受けた試験（2026年7月3日、改定前）：180問（採点対象175＋事前テスト5）、230分。60問目と120問目のあとに、10分ずつの休憩 - 今の試験（2026年7月9日から）：180問（採点対象170＋採点対象外10）、240分。ケーススタディのセクションが先に出て、休憩はケーススタディが終わったあとに1回、残りの問題の半分ほどのところで1回あります。休憩のあとは、前の問題に戻れません。 以下の時間配分の体験は、改定前の試験にもとづいています。変わった点の全体は[第5部：2026年PMP試験改定まとめ](/ja/posts/pmp-2026-exam-changes-pmbok-8)に、ケーススタディの対策は[第9部：ケーススタディ問題の対策](/ja/posts/pmp-case-study-questions)にまとめました。 ## 試験当日をひと目で | 項目 | 私の場合 | |---|---| | 試験日・時間 | 2026年7月3日（金）午前10時15分 | | 試験会場 | Pearson Professional Center Seoul（中区ムギョロ21、The Exchange Seoul 6階） | | 試験の言語 | 韓国語 | | 予約時間 | 270分（230分の試験に、チュートリアル、同意手続き、アンケートの時間を含む） | | 当時の試験構成 | 180問（採点対象175＋事前テスト5）、230分 | | セッション構成 | 60問ずつ3セッション | | 休憩 | セッションの間に10分ずつ2回 | | 最初の60問にかかった時間 | 約80分 | | 用意したおやつ | チョコバー、クルミ、アーモンド | | 最終結果 | PASS | 試験の構造だけ見ると、「60問ずつ3回解けばいい」と思いがちです。でも、約4時間にわたって似たような状況問題を読み続け、判断し続けるのは、思っていたよりずっと疲れました。 ## 予約確認メールに書かれていたこと 6月13日の未明に試験の予約を終えると、Pearson VUEから確認メールが届きました。私に届いたメールは韓国語で、試験当日に必要な情報は、ほぼすべてここに入っています。 Pearson VUEの韓国語の予約確認メール。試験PMP-CBT 韓国語（KOR）、2026年7月3日（金）午前10時15分、予約時間270分、Pearson Professional Center Seoul、中区ムギョロ21 The Exchange Seoul 6階 *2026年6月13日に届いたPearson VUEの予約確認メール。注文番号、PMI ID、登録IDは隠してあります。* - 試験：PMP-CBT、韓国語（KOR） - 日時：2026年7月3日（金）午前10時15分（センターの現地時間） - 予約時間：270分 - 会場：Pearson Professional Center Seoul、中区ムギョロ21 The Exchange Seoul 6階 試験は230分なのに、予約時間は270分です。この時間の中に、試験前のチュートリアルと同意手続き、試験が終わったあとのアンケートまで含まれているからです。今の試験は試験時間そのものが240分なので、予約時間もメールで必ず確認し直してください。 申請書の提出から受験料の支払い、Pearson VUEで日にちとセンターを選ぶまでの流れは、[第3部：受験申請からPearson VUE予約まで](/ja/posts/pmp-application-pearson-vue-booking)に、実際のメールと一緒にまとめました。 ## 試験会場のルール：30分前に到着、身分証明書、ロッカー 予約確認メールとPMIのハンドブックに書かれている当日のルールを、まず整理します。センターによって細かい案内は違うことがあるので、自分のメールも必ず確認してください。 - **到着時間**：予約時間の30分前までに到着して、チェックインします。15分を超えて遅れると入室を断られることがあり、その場合、受験料は返ってきません。 - **身分証明書**：氏名、写真、署名のある、有効な政府発行の身分証明書の原本が必要です。氏名は予約情報と完全に一致していなければなりません。予約の氏名はローマ字表記なので、ローマ字の氏名が載っているパスポートがいちばん確実です。 - **ロッカー**：私物はロッカーに入れます。身につけていられるのは、身分証明書とロッカーの鍵くらいです。 - **電卓**：試験画面に電卓が入っています。 - **韓国語の試験**：問題と画面は韓国語で表示され、各問題にあるExhibitボタンを押すと、英語の原文を見られます。韓国語と英語を並べて表示する方式ではありません。 私は、ローマ字の氏名と身分証明書の情報が予約情報と一致しているかも、もう一度確認しました。身分証明書の問題で入室できなかったら、それまでの勉強時間が水の泡ですから。 ### 実際に到着してみると 勉強中にFull Mockも解いて、ある程度は準備ができたと思っていましたが、試験会場に入ると、まったく感覚が違いました。 本人確認をして私物を片づけ、席に座った瞬間から、緊張が高まってきました。画面に最初の問題が出ると、いつもより文章を長く読んでしまい、簡単な選択肢まで疑い続けるようになりました。 ## 本番：最初の60問に80分 ### 予想より難しく感じた 個人的には、本番は思っていたより難しかったです。Study Hallで似た形式の問題をたくさん見ていたのに、試験会場では緊張のせいで、選択肢どうしの小さな違いがより大きく感じられました。 問題ごとに、こんな考えがくり返し浮かびました。 - どちらも正しそうだけど、何を先にやるべき？ - この状況は分析が先？それとも行動が先？ - 今はエスカレーションする段階？ - アジャイルの状況？それとも予測型の状況？ - 問われているのは`FIRST`？それとも`NEXT`？ まったくわからない問題より、2つの選択肢のどちらかを選ぶ問題のほうが、ずっとエネルギーを消耗しました。すべての問題で確信を得ようとすると、時間はあっという間に消えていきました。 ### 最初の60問に80分かかった 最初のセッションの60問を解くのに、約80分かかりました。最初の休憩で外に出たとき、「このペースだと、後半で時間が足りなくなるのでは？」という考えが浮かびました。 最初のパートに時間がかかった理由は、単純でした。 - 緊張して、問題文を何度も読み返した。 - 確信を持って選んだ答えまで見直した。 - 難しい問題から、すぐに次へ進めなかった。 - 全体の時間より、目の前の1問にばかりしがみついていた。 最初の休憩では、点数や難しかった問題を思い出さないようにしました。水を飲み、チョコバーとナッツを少し食べ、首と肩をストレッチしました。短い時間でも、画面と問題から完全に離れるのが効きました。 席に戻ってからは、戦略を変えました。 > **確実にわかる問題は、読み返さずに先へ進む。難しい1問に、あとに控える簡単な問題の時間を奪わせない**。 それからは、問題が`FIRST`、`NEXT`、`BEST`のどれを聞いているのかをまず見て、明らかに間違っている選択肢を消してから決めるようにしました。おかげで、最後のセッションでは少し時間が余りました。 ### 私に合っていた時間配分のやり方 もう一度受けるなら、1問あたりの時間をきっちり均等に割り振ることはしません。そのかわり、60問単位で残り時間を確認し、1問に長くとどまる場面を減らします。 1. **問題が求める行動を先に見る**。状況説明を読む前に、最後の文でPMが「最初に」「次に」、あるいは「どのように」すべきかを確認すると、問題の焦点が少し見えやすくなりました。 2. **明確な問題は一度で終わらせる**。確実な答えを選んだのに、不安だというだけで読み返すと、時間が積み重なります。本当に見直しが必要な問題と、緊張のせいで疑っているだけの問題を区別するようにしました。 3. **難しい問題は時間を決めて解く**。2つの選択肢がどうしても残るときは、キーワードとPMPマインドセットをもう一度確認して決めました。1問で完璧な確信を得るより、試験全体を終わらせることのほうが大事でした。 4. **セッションが終わる前に残り時間を見る**。1問ごとに時計を見ると、集中が途切れます。一定の間隔で、そしてセッションが終わる前に残り時間を確認するやり方のほうが、私には合っていました。 ## 10分の休憩は思ったより短い Pearson VUEのセンターで受験するなら、休憩時間は自分で管理してください。**10分は本当にあっという間です**。 トイレに行き、おやつを食べ、再入室のときに本人確認とセキュリティチェックを受けると、時間はすぐに過ぎます。私は最初の休憩で、10分を少しオーバーしてしまいました。 センターの入口や案内された場所で時計を確認してから動くのがおすすめです。携帯電話は使えなかったり、触れることが制限されたりする場合があるので、携帯で時間を見ればいいと考えないほうが安全です。正確な手順は、そのセンターの案内に従ってください。 ### 休憩中に実際にやったこと 1. 水を飲んだ。 2. チョコバーとナッツを少し食べた。 3. 首、肩、腰をストレッチした。 4. 終わった問題を思い出さなかった。 5. 残り時間と次のセッションの戦略だけを確認した。 休憩中に問題を振り返ると、もう終わったセッションへの不安が大きくなるだけです。私は、頭を空っぽにして体を動かすほうが、ずっとよかったです。 ### 試験会場に持っていってよかったもの センターの規定を先に確認するという前提で、私にはこんな準備が役立ちました。 - 予約情報と一致する、有効な身分証明書 - チョコバーのように、すぐ食べられるおやつ - クルミやアーモンドのようなナッツ類 - 水 - 室温に合わせて脱ぎ着しやすい服 - 試験会場の場所と到着時間のメモ おやつをたくさん食べるより、休憩中に負担にならない程度に、糖分とエネルギーを少し補給するのがよかったです。首、肩、腰を軽くほぐすのも、次のセッションの集中力を取り戻すのに役立ちました。 ## 試験前にやっておきたいこと ### 4時間の模擬試験を一度は最後まで 短い問題セットでいい点を取ることと、約4時間判断し続けることは、まったく別の体験でした。Full Mockを最後まで解いてみると、知識以外にもこんなことを確認できます。 - どのセッションで集中力がいちばん落ちるか？ - 最初の60問を解くのが遅すぎないか？ - 休憩のあと、再び集中するまでどれくらいかかるか？ - 水とおやつはどれくらいとれば快適か？ - 長く座っていても、首や腰は大丈夫か？ できれば本番と同じように、携帯電話を遠ざけ、時間を計り、決められた休憩だけを使ってみてください。試験当日に初めて経験することを、ひとつでも減らせます。 ### 試験の2日前からは間違いノートだけ 試験直前にいちばん役立ったのは、本を最初から読み直すことではありませんでした。間違えた問題を見直しながら、**なぜ間違えたのかを自分で説明してみること**でした。だから試験の2日前からは、新しい内容を入れるより、間違いノートとマインドセットの2つだけをくり返しました。 間違いノートでは、正解の文より、自分がくり返したミスを見ました。 - 問題を最後まで読まなかった。 - `FIRST`と`NEXT`を区別しなかった。 - チームと話す前にエスカレーションした。 - 原因を探す前に、解決策から選んだ。 - 変更の影響を分析する前に実行した。 - 予測型とアジャイルの状況を混同した。 私が使った間違いノートのフォーマットと無料のWordテンプレートは、[第6部：PMP間違いノートの書き方](/ja/posts/pmp-error-log-method)にあります。 ### PMPマインドセットは短く 試験直前には、膨大なプロセスの一覧より、判断の基本的な順番を短く復習しました。 > **状況の把握 → 原因の確認 → チームとの協働 → 影響の分析 → 手順に沿った行動** すべての問題にそのまま当てはまる公式ではありません。でも、緊張した状態で強すぎる措置を焦って選ばないよう、踏みとどまらせてくれる基準になりました。 ### AIは解答集ではなく、復習のパートナー ChatGPTとNotebookLM（現 Gemini Notebook）は、間違いノートの整理、マインドセットの復習、紛らわしい概念の比較に役立ちました。特に試験直前は、散らばっていた内容を短い質問と要約に変えるのに便利でした。 でも、PMPの問題をそのまま入力して、AIが選んだ選択肢だけを確認するやり方はおすすめしません。AIは選択肢どうしの微妙な違いを読み違えることがありますし、もっともらしい説明で、間違った答えを自信たっぷりに出すこともあります。AIを使うときも、次のプロセスは自分でやる必要があります。 1. 自分がなぜその答えを選んだのかを、先に書く。 2. 公式の解説と出典を確認する。 3. AIには、正解より自分の思考プロセスの穴を聞く。 4. 説明が食い違ったら、公式の資料を基準に検証し直す。 5. 最後に、自分の言葉で1行の原則を残す。 ChatGPTへの質問のコツとNotebookLMの活用法は、[第7部：GPTで概念を確認し直し、NotebookLMの音声で通勤復習](/ja/posts/pmp-gpt-notebooklm-study)に詳しくまとめました。 ## 結果シートを受け取ったとき 試験が終わってPASSを確認したとき、真っ先にわいてきた感情は安堵でした。準備中は、低い点数や難しい問題を見るたびに揺れましたが、結局はその間違いが、試験会場でもう一度考えさせてくれる材料になりました。 ドメイン別の結果は、PeopleがBelow Target、ProcessがTarget、Business EnvironmentがAbove Targetでした。1つのドメインがBelow Targetだったのに、全体の結果はPASSでした。ただ、これはあくまで私個人の結果で、ドメイン別の評価からPMIの合格基準を簡単に計算できるという意味ではありません。 私のStudy Hallの点数は、Full Mockで66%と65%、全体の平均が約62%でした。この点数で受かりましたが、「60%なら絶対に合格」とは言いたくありません。そのかわり、間違えた理由を自分の言葉で説明できるか、同じミスをくり返していないか、Full Mockを本番の時間内に終えられるか、答えを暗記せずにPMIの判断の順序を当てはめられるかを確認してみてください。解いてきた問題も、間違いの分析の深さも、試験当日のコンディションも、人それぞれ違うからです。点数ひとつより、これらの問いのほうが準備状況をよく表していました。点数の話は[第1部](/ja/posts/pmp-pass-review-part-1)に詳しく書いています。 ## 最後に伝えたいこと 間違えたときに「自分はダメなのかな」と考えるより、「この問題は、本番で正解できる確率が上がった問題だ」と受け止めてもらえたらと思います。試験の前に間違えてよかった問題も、きっとあります。 大事なのは点数そのものより、間違いを通して**自分がどんなふうに判断を誤るのかを突き止めること**でした。 試験の準備中なら、新しい教材をどんどん増やすより、すでに勉強した内容を自分の判断基準にすることに時間を使ってください。そして試験の前に、約4時間、実際に座ってみてください。知識、体力、時間管理がそろって準備できているとき、ずっと落ち着いて解けます。 今まさに準備しているみなさんを、心から応援しています。ファイト！💪🍀 **次の記事**：[PMPの受験申請からPearson VUEの予約まで：6月1日に申請、6月13日に予約完了](/ja/posts/pmp-application-pearson-vue-booking) **最初から読む**：[PMP合格体験記 第1部：7週間の準備と、Study Hall 60%台からPASSまで](/ja/posts/pmp-pass-review-part-1) ## 参考資料 - [PMI Certification Handbook（PDF）](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/generic-certification-handbook.pdf) — チェックインの手順、身分証明書、日程変更とキャンセル、試験言語の規定 - [Pearson VUE：PMI試験の案内](https://www.pearsonvue.com/us/en/pmi.html) - [PMI公式のPMP案内ページ](https://www.pmi.org/certifications/project-management-pmp) - [2026 PMP Examination Content Outline（PDF）](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf) - [PMIブログ：PMP試験の変更について（2026年7月10日）](https://www.pmi.org/blog/pmp-exam-change) --- # PMP合格体験記 第1部：7週間の準備と、Study Hall 60%台からPASSまで（費用・日程まとめ） > 2026年7月3日にPMPに合格しました。申請からPASSまでの日程、Study Hallと受験料で実際に払った$499.40、模擬試験66%・65%で受かった7週間の勉強法を、領収書とメールをもとにまとめました。 _Slug: pmp-pass-review-part-1 · 2026-07-03_ こんにちは。**2026年7月3日（金）、PMP試験を受けて、最終結果はPASSでした**。 試験の準備中は、韓国のPMPコミュニティの合格体験記や[Reddit r/PMP](https://www.reddit.com/r/pmp/)の投稿を、ほぼ毎日読んでいました。Study Hallの点数が同じくらいの人も受かっているのか、本番はどれくらい難しいのか、試験当日は何を持っていけばいいのか。調べるたびに、本当に助けられました。 いつも人の合格体験記を読むばかりだったので、自分が書く側になると、なんだか不思議で、うれしい気持ちです。合格から3か月たった今、メールボックスに残っていた領収書や案内メールまで掘り起こして、この記事を一から書き直しました。点数が不安な方や、どこから手をつければいいかわからない方にとって、小さな地図になればうれしいです。 **3行まとめ**：約7週間準備して、2026年7月3日にPMPに合格しました。申請書を出してからPASSまでは32日です。実際に払ったのはStudy Hallの$53.90と受験料の$445.50（PMIの会費は別）で、問題集はStudy Hall Essentialsだけで十分でした。模擬試験は66%と65%、全体の平均は約62%でしたが、結果はPASSでした。 **この体験記は改定前の試験にもとづいています**。私が受けた7月3日の試験は180問（採点対象175＋事前テスト5）、230分でした。2026年7月9日から実施されている新しい試験は、次のように変わりました。 - 180問＝採点対象170＋採点対象外10、試験時間240分 - 長いケースを1つ読んで、続けて複数の問題に答えるケーススタディのセクションが最初に出る - ドメインの比率：People（人）33%、Process（プロセス）41%、Business Environment（ビジネス環境）26%（従来は42%、50%、8%） 数字がかなり変わったので、試験の構成は[第5部：2026年PMP試験改定まとめ](/ja/posts/pmp-2026-exam-changes-pmbok-8)で必ず確認してください。ケーススタディの対策は[第9部](/ja/posts/pmp-case-study-questions)に別にまとめています。 ## PMP合格までをひと目で 申請書を出した日から最初のPDUが承認された日まで、メールボックスに残っている日付をそのまま書き写しました。 書類上の日程だけ見ると、6月1日の申請書提出から7月3日の試験まで、1か月ちょっとです。承認までに8日かかり、受験料を払った翌日の未明には、試験の予約まで終わっていました。申請書の作成から承認、支払い、Pearson VUEでの予約までは、実際のメールと一緒に[第3部：受験申請からPearson VUE予約まで](/ja/posts/pmp-application-pearson-vue-booking)でステップごとに説明しています。経歴の書き方や監査（Audit）が心配なら、[第4部：経歴の書き方と監査](/ja/posts/pmp-experience-application-audit)から読んでもかまいません。 ### 私のPMP準備の結果まとめ | 項目 | 内容 | |---|---| | 試験日 | 2026年7月3日（金）午前10時15分 | | 受験形式 | Pearson VUEのテストセンター（ソウル中区ムギョロ）、韓国語で受験 | | 準備期間 | 約7週間 | | 主な教材 | オンライン講義、PMI Study Hall Essentials、間違いノート | | Study Hall Full Mock 1 | 66% | | Study Hall Full Mock 2 | 65% | | Study Hall全体の平均 | 約62% | | 補助ツール | ChatGPT、NotebookLM（現 Gemini Notebook） | | 実際の支払額 | $499.40（Study Hall＋受験料、PMIの会費は別） | | 最終結果 | PASS | ## PMPの費用：私が実際に払ったお金 「PMP 費用」で検索すると、出てくる数字はバラバラです。為替レートも違えば、会員価格と通常価格が混ざっていたり、税抜きの金額だったりもします。そこで、私の決済メールに載っている金額だけをそのまま書きます。 | 項目 | 支払日 | 価格 | 税 | 支払額 | |---|---|---|---|---| | PMI Study Hall Essentials（3か月のサブスクリプション） | 2026.06.01 | $49.00 | $4.90 | $53.90 | | PMP受験料（会員価格） | 2026.06.12 | $405.00 | $40.50 | $445.50 | | 合計 | | $454.00 | $45.40 | **$499.40** | どちらも、価格の10%が税として加算されました（韓国からの支払いです）。ドル建てで払ったので、ウォンでいくら引き落とされたかは、カード会社の為替レートによって変わります。 PMI Study Hall Essentialsの決済メール。購入日2026年6月1日、価格$49.00、税$4.90、合計$53.90 *2026年6月1日に届いたStudy Hall Essentialsの決済メール。$49に税$4.90で、合計$53.90です。注文番号は隠してあります。* PMP受験料の決済メール。購入日2026年6月12日、受験料$405.00、税$40.50、合計$445.50 *2026年6月12日に届いたPMP受験料の決済メール。会員価格$405に税$40.50で、合計$445.50です。注文番号は隠してあります。* ### PMIの会費は別。それでも入会したほうが得 上の表には、PMIの会費が入っていません。私は6月1日に入会しました。今（2026年10月）、韓国向けPMIストアの会費の通常価格は$139です。これは現在の価格で、私が6月に払った金額ではありません。 それでも、入会はしておいたほうがいいです。計算は簡単です。 - 受験料：会員$405、非会員$655。1回の受験で、**差額は$250**なので、会費$139を払っても$111が残ります。 - 再受験：会員$275、非会員$375で、$100の差 - 3年ごとの資格更新：会員$60、非会員$150で、$90の差 - PMBOKガイド第8版のPDFが無料 受験料の割引だけで、会費の元は十分に取れます。ただし、価格は地域によって異なります。たとえばPMIの米国ストアでは、受験料が会員$425・非会員$675、会費は$164です。会員価格が表示されたPMIの画面と、私が入会した順番は、[第3部](/ja/posts/pmp-application-pearson-vue-booking)でお見せします。 ## 問題集はStudy Hall Essentialsだけで十分でした PMPの準備をしていると、問題集をいくつ買えばいいのか悩むものです。結論から言うと、私はPMIが自ら作っている**Study Hall Essentials**の3か月サブスクリプションひとつで済ませましたし、それで十分でした。 私が申し込んだ当時、Essentialsには本番と同じ長さの模擬試験（Full Mock）が2回分、ミニ模擬試験が15回分、追加問題が200問入っていました。Full Mock 2回を時間を計って最後まで解き、間違えた問題を間違いノートにまとめるだけでも、やることは十分にあります。PMIが自ら作った問題なので、形式も本番に近いです。とはいえ、[第2部](/ja/posts/pmp-pass-review-part-2)に書いたとおり、試験会場ではずっと難しく感じたのですが。 6月1日に3か月分を払い、7月3日に受験したので、利用期間の3分の1ちょっとしか使わなかったことになります。残りの期間はそのまま過ぎて、9月1日に期限が切れました。 myPMIの「Your Online Tools」画面の期限切れ（Expired）タブ。PMI Study Hall Essentials PMPの四半期サブスクリプションが2026年9月1日に期限切れと表示されている *myPMIの「Your Online Tools」画面。6月1日に支払ったStudy Hall Essentialsの3か月サブスクリプションは、2026年9月1日に期限が切れました。* ### 今Study Hallを買うなら その後、価格と内容が少し変わりました（2026年10月時点）。 | 区分 | 価格 | 内容 | |---|---|---| | Essentials | 3か月$59 | 本番形式の模擬試験2回（各180問）、ミニ模擬試験10回、追加問題330問 | | Plus | 3か月$79 | 本番形式の模擬試験3回 | 会員も非会員も同じ価格で、英語のみの提供です。翻訳が必要な場合、PMIはGoogle翻訳の拡張機能を使うよう案内しています。私の感覚では、今もEssentialsで十分です。模擬試験の数を増やすより、2回分をきちんと解いて振り返るほうがずっと大事だと思います。 ## 模擬試験60%台でも合格できる 私のStudy Hallの点数は、Full Mock 1が66%、Full Mock 2が65%、全体の平均は約62%でした。そして結果はPASSでした。 正直、準備中はこの点数にまったく安心できませんでした。高得点の合格体験記を読めば読むほど、「この点数で受けて大丈夫だろうか」という気持ちばかりが大きくなりました。だから、同じことで悩んでいる方に、まずこれを伝えたいです。**60%台でも受かります**。少なくとも、私はそうでした。 2026年7月3日のPMP試験の合格結果と、ドメインごとの成績が記載された結果シート *試験直後にPearson VUEのセンターで受け取った結果シート。全体の結果はPASSで、ドメイン別ではPeopleがBelow Target、ProcessがTarget、Business EnvironmentがAbove Targetでした。* PeopleがBelow Targetだったのに、全体の結果はPASSでした。ただ、これはあくまで私の結果で、ドメイン別の評価からPMIの合格ラインを計算できるという意味ではありません。 ### 点数より大事だった3つのこと 振り返ってみると、点数そのものより大事だったのは、**どんな考え方のせいで同じ間違いをくり返しているのかを見つけること**でした。次の3つのほうが、点数よりも私の準備状況をよく表していました。 - 同じ理由で間違える問題は減っているか？ - 正解を暗記せずに、判断のプロセスを説明できるか？ - 本番の試験時間中ずっと、集中力を保てるか？ もちろん、私の点数がすべての人の合格基準になるわけではありません。Study Hallの点数と実際の結果の関係は、人によって違います。それでも、60%台前半〜半ばという数字ひとつで、準備のすべてを否定する必要はないと言いたいです。 間違えた問題は「自分はまだ準備ができていない」という判定ではなく、**本番の前にもう一度正解するチャンスをくれた問題**でした。 ## 7週間の勉強法：講義、Study Hall、模擬試験、間違いノート 勉強は大きく4つのステップで進めました。その前に、PMPがどんな試験なのか、なぜ改定前の試験を選んだのかに簡単に触れておきます。 ### PMPはどんな試験か PMP（Project Management Professional）は、PMI（Project Management Institute）が運営するプロジェクトマネジメントの資格です。特定の業界や方法論にしばられず、プロジェクトを率いながら**人、プロセス、ビジネスの優先順位**を扱えるかどうかを見ます。 PMBOKをどれだけ暗記したかを問う試験とは、まったく違います。ほとんどの問題はプロジェクトで起こりそうな状況を示し、そのときプロジェクト・マネージャーが**最初に**、あるいは**次に**何をすべきかを選ばせます。だから用語を覚えるよりも、問題を見る順番や、PMIがPMに期待する姿勢を身につけるほうが、ずっと大事でした。 受験するには、学歴に応じたプロジェクト経験（学士なら36か月）と、35時間のプロジェクトマネジメント教育が必要です。受験資格と経歴の書き方は[第4部](/ja/posts/pmp-experience-application-audit)に、CAPMやPMI-ACPとの違いは[第10部：PMP vs CAPM vs PMI-ACP](/ja/posts/pmp-vs-capm-vs-pmi-acp)にまとめました。 ### なぜ7週間で改定前の試験を受けたのか 最初は新しい試験を受けるつもりで、余裕を持って始めました。教材もPMBOKガイド第8版を使っていました。 ところが、オンライン講義を思ったより早く終えられたうえに、改定前に受けられる試験日程もまだ残っていました。すでに学んだ核となる原則は旧試験にもそのままつながっていたので、準備期間を延ばすより、当時の試験に合わせて集中して受けることにしました。 このとき大事だったのは、最新の本を読んだことよりも、**自分が受ける試験の試験内容概要（Exam Content Outline、ECO）と問題形式に、勉強の内容を合わせ直したこと**でした。教材の版だけで決めず、自分の試験日に適用される公式の出題基準をまず確認してください。PMBOK第7版と第8版の違いも、[第5部](/ja/posts/pmp-2026-exam-changes-pmbok-8)にまとめています。 ### ステップ1：オンライン講義で全体像をつかむ 最初からPMBOKを細かく暗記しようとはしませんでした。オンライン講義を聞きながら、予測型（Predictive）、アジャイル（Agile）、ハイブリッドのアプローチがどう違うのか、状況ごとにPMがどんな役割を果たすべきかという、大きな流れからつかみました。 平日は仕事のあと、少しでも講義を聞きました。余力のある日は何本かまとめて聞き、疲れた日は短いパートをひとつだけでも終わらせました。週末は、平日に聞いた内容を復習したり、問題を解いたりしました。 私はもともと、仕事のあとに長時間座って勉強できるタイプではありません。だから1日の勉強量を完璧に守ることより、**勉強をまったくしない日を減らすこと**に集中しました。 講義はオンラインで十分でした。最初は高い対面講座まで受けるべきか迷いましたが、私にはオンライン講義で骨組みをつくり、Study Hallの問題を解きながら間違いを分析する組み合わせが合っていました。講義を最後まで聞いたという事実だけでは、本番で選択肢を選べるようにはなりませんでした。実力が伸びたのは、**問題を解き、間違え、判断のプロセスを整理し直す時間**でした。 なお、2026年12月1日からは、35時間の教育の認定基準が変わります。リアルタイム（ライブ）の講義は、PMIの認定トレーニングパートナー（ATP）や認定を受けた大学のプログラムなどで受けたものだけが認められ、自分のペースで進めるオンライン講義（self-paced）は、どこで受けたものでも引き続き認められます。本や模擬試験だけでは認められません。 ### ステップ2：Study HallでPMI流の判断を身につける 基本の講義を聞いたあと、いちばん使ったのがPMI Study Hallでした。問題を解いてみると、概念を知らないのか、問題文を読み違えたのか、それともエスカレーション（上位への報告・委譲）を早く選びすぎているのかが、すぐにわかりました。 最初は正解の数しか見ていませんでした。点数が低ければ勉強不足だと思い、高得点の体験記を探せば探すほど不安になりました。でも問題をくり返し解くうちに、同じ点数でも、その中に含まれる情報は違うと気づきました。 - 概念そのものを知らなくて間違えた問題 - `FIRST`、`NEXT`、`BEST`のような問いの意図を見落とした問題 - 問題文にない状況を勝手に想定した問題 - すぐにスポンサーや上位の組織に回してしまった問題 - チームと話す前に、メンバーを入れ替えようとした問題 - 変更の影響を分析する前に実行した問題 間違えた理由をこう分けると、点数はただの成績表ではなく、次に何を勉強すべきかを教えてくれる材料になりました。 ### ステップ3：Full Mockで4時間を乗り切る Full Mockの点数は、先に書いたとおり66%と65%でした。ただ、私はFull Mockの目的を、合格できるかどうかの予測だけには置きませんでした。長時間集中力を保てるか、どのあたりでペースが落ちるか、休憩のあとでまた問題に没頭できるかを確かめました。 PMP試験は、知識と同じくらい体力と時間管理も問われます。短い問題セットばかり解いて本番に行くと、試験の疲れを当日初めて味わうことになります。試験前に一度は、時間を計ってFull Mockを最初から最後まで解いてみてください。本番で最初の60問に80分かけてしまった話は、[第2部](/ja/posts/pmp-pass-review-part-2)に詳しく書きました。 ### ステップ4：新しい問題より間違いノート 試験が近づいてからは、新しい問題をあまり増やしませんでした。すでに間違えた問題を見直しながら、2つの問いに答えようとしました。 > 「なぜ自分はこの選択肢を選んだのか？」 > 「ほかの選択肢より、この答えのほうがPMIの視点で適切なのはなぜか？」 正解の文を暗記すると、似た状況で言葉が少し変わっただけで、また間違えました。逆に、自分の判断プロセスを説明できれば、初めて見る問題にも同じ原則を当てはめられました。私にはこれがいちばん効きました。私が使った間違いノートのフォーマットと無料のWordテンプレートは、[第6部：PMP間違いノートの書き方](/ja/posts/pmp-error-log-method)で公開しています。 ### GPTとNotebookLMは解答集ではなく、復習のパートナー 準備中は、ChatGPTとNotebookLMもたくさん使いました。AIは正解を代わりに選んでくれる道具というより、私が理解した内容を説明し直したり、比べたりしてくれる復習のパートナーでした。ChatGPTには「PMP 시험공부」（PMP試験勉強）というプロジェクトを別に作り、間違いの整理と概念の質問を一か所に集めました。 - 紛らわしい2つの概念を表で比べる - 自分が選んだ答えの思考プロセスを説明し、抜けている前提を質問してもらう - 間違いの原因を、概念不足、問題の読み違い、マインドセットの誤りに分ける - 複雑な概念を、実際のプロジェクトの例で説明し直してもらう - まとめた内容から、短い復習問題をつくる 正解だけを教えてもらうのではなく、こんなふうに聞きました。 ```text この状況で、私はすぐにスポンサーへ報告すべきだと判断した。 私の判断に隠れている前提を見つけて、 PMIの視点でまず確認すべき行動を、質問の形で教えて。 正解をすぐに言わずに、私がもう一度判断できるように手伝って。 ``` NotebookLMには間違いノートと復習資料を集めて、資料の中でくり返し出てくるテーマを探すのに使いました。1つのノートブックにソースが155個までたまり、上限いっぱいになりました。ここで作った韓国語の音声解説（Deep Dive）は1本12〜24分ほどで、通勤中に1本ずつ聞くのにちょうどいい長さでした。ちなみに、NotebookLMは2026年7月から、Gemini Notebookという名前に変わっています。 主に使ったのは、こんなことです。 - よく間違えるマインドセットだけを集めて要約する - アジャイルと予測型の状況を分けて復習する - 変更管理と対立のマネジメントのように、混同しやすいテーマを比べる - 試験直前に確認する短い復習リストを作る 資料が混ざると、AIが何を根拠に答えたのか確かめにくくなります。だから、出典がはっきりした公式資料と、自分で確認したノートを中心に置きました。ChatGPTの使い方とNotebookLMのノートブック構成は[第7部](/ja/posts/pmp-gpt-notebooklm-study)に、通勤時間の使い方と単語帳は[第8部](/ja/posts/pmp-commute-study-vocabulary)にまとめています。 Study Hallの問題をそのままAIに入れて、AIが選んだ答えだけを見て答え合わせをするやり方は、おすすめしません。PMPの問題は、選択肢どうしの微妙な違いと状況の文脈が大事です。AIの説明も間違うことがあるので、公式の資料と解説を基準に、自分で検証してください。 ## 試験で役立ったPMPマインドセット PMPマインドセットを、どんな場合にも当てはまる暗記用の公式だとは考えていませんでした。倫理、法令、安全、緊急のリスクのように、すぐに対応すべき例外もあるからです。ただ、よくある対立や変更の場面では、次の順番が判断の助けになりました。 1. **行動する前に、まず状況と原因を把握する**。 2. **チーム内で解決できる問題は、まずチームと話し合う**。 3. **すぐにエスカレーションしたり、スポンサーに丸投げしたりしない**。 4. **メンバーを入れ替える前に、コーチング、協働、対立の解消を試みる**。 5. **問題の症状より、根本原因（Root Cause）を探す**。 6. **変更要求は、影響を分析したうえで正式な手順どおりに処理する**。 7. **プロジェクト・マネージャーはチームを統制するより、支援して障害を取り除く**。 実際の問題では、どの選択肢ももっともらしく見えました。そんなときは、「今すぐいちばん強い措置をとる答え」より、「状況を理解して、チームが解決できるよう支援する答え」のほうが正解であることが多かったです。 ## 合格、そのあと 試験の翌日、7月4日の午前3時33分に、PMIからPMPを取得したというメールが届きました。結果シートですでに知ってはいましたが、PMIからの公式なお祝いメールは、これが初めてでした。 PMIから届いたPMP取得のお祝いメール。You earned your Project Management Professional (PMP) Professional Certificationの文言と、Credlyのデジタルバッジの案内 *2026年7月4日に届いたPMP取得のメール。Credlyのデジタルバッジは、1〜2週間以内に別途届くと書かれています。* PMPは3年ごとに更新が必要で、その間にPDUを60集めなければなりません。私は8月31日にPMIのウェビナー「Why Some Projects Fail: The Sponsor's Role」を視聴し、9月3日に最初のPDU（1.00 PDU）が承認されました。3年で60 PDUをどう集めるかは、[第11部：3年で60PDU、私のPMP維持計画](/ja/posts/pmp-60-pdu-renewal-plan)にまとめています。 合格後の話も続きます。資格を取って会社の仕事で実際に何が変わったかは[第12部](/ja/posts/pmp-what-changed-at-work)に、なぜPMではない人にこそPMPが強力だと思うのかは[第13部](/ja/posts/pmp-for-non-project-managers)に、年収や採用まで含めてPMPに本当に効果があるのかは[第14部](/ja/posts/is-pmp-worth-it-salary-benefits)に書きました。最近はPMI韓国支部の教育委員会でボランティアもしていて、その話は[第15部](/ja/posts/pmi-korea-chapter-education-committee)にあります。 ## 「PMP合格ロードマップ」シリーズ一覧 申請から合格、その後までを、15本の記事にまとめました。必要な記事から選んで読んでいただいてもかまいません。 **合格記録と申請手続き** 1. PMP合格体験記 第1部：7週間の準備と、Study Hall 60%台からPASSまで（今読んでいる記事） 2. [PMP合格体験記 第2部：試験当日の時間配分と、合格のための最後のアドバイス](/ja/posts/pmp-pass-review-part-2) 3. [PMPの受験申請からPearson VUEの予約まで：6月1日に申請、6月13日に予約完了（実際のメールを公開）](/ja/posts/pmp-application-pearson-vue-booking) 4. [PMP経歴の書き方とAudit（監査）：6月1日申請→6月9日承認、私のPM経歴はこうまとめました](/ja/posts/pmp-experience-application-audit) **試験の理解と勉強法** 5. [2026年PMP試験改定まとめ：変わったこと、そしてPMBOK第7版 vs 第8版](/ja/posts/pmp-2026-exam-changes-pmbok-8) 6. [PMP間違いノートの書き方：間違えた問題を「判断ルール」に変える6ステップ（無料Wordテンプレート付き）](/ja/posts/pmp-error-log-method) 7. [GPTで概念を確認し直し、NotebookLMの音声で通勤復習：私のPMP AI勉強ルーティン](/ja/posts/pmp-gpt-notebooklm-study) 8. [通勤時間のPMP勉強法：短く濃く、こまめに見る（＋合格者の単語帳）](/ja/posts/pmp-commute-study-vocabulary) 9. [PMPケーススタディ問題の対策：2026年の新形式は、こう読んでこう解く](/ja/posts/pmp-case-study-questions) **資格の比較と維持** 10. [PMP vs CAPM vs PMI-ACP 比較：自分に合うのはどれ？（2026年版）](/ja/posts/pmp-vs-capm-vs-pmi-acp) 11. [3年で60PDU、私のPMP維持計画：最初のPDU承認メールから公開します](/ja/posts/pmp-60-pdu-renewal-plan) **合格、その後** 12. [PMP取得後、仕事で変わったこと：資格よりも「話し方」が変わった](/ja/posts/pmp-what-changed-at-work) 13. [PMPは、PMではない人にこそ効く：開発者やデザイナーがPMの目で働くとき](/ja/posts/pmp-for-non-project-managers) 14. [PMPって、結局効果ある？実務・年収・採用での優遇まで正直にまとめました](/ja/posts/is-pmp-worth-it-salary-benefits) 15. [PMI韓国支部の教育委員会でボランティアを始めました：合格体験記のその後](/ja/posts/pmi-korea-chapter-education-committee) ## 第1部のおわりに 7週間でいちばん大きく変わったのは、覚えた知識の量より、問題を見る順番でした。すぐに行動する前に状況を確かめ、メンバーを入れ替える前に話し合い、変更する前に影響を分析する。そんなやり方が、少しずつ身についていきました。 次の記事では、Pearson VUEの試験会場に入った瞬間から、最初の60問に80分かけてメンタルが揺らいだ話、10分の休憩、おやつとストレッチ、最後のセッションの時間配分までをまとめています。 **続けて読む**：[PMP合格体験記 第2部：試験当日の時間配分と、合格のための最後のアドバイス](/ja/posts/pmp-pass-review-part-2) ## 参考資料 - [PMI公式のPMP案内ページ](https://www.pmi.org/certifications/project-management-pmp) - [2026 PMP Examination Content Outline（PDF）](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf) - [PMIブログ：PMP試験の変更について（2026年7月10日）](https://www.pmi.org/blog/pmp-exam-change) - [PMI Certification Handbook（PDF）](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/generic-certification-handbook.pdf) - [PMI Study Hall Essentialsの商品ページ](https://www.pmi.org/shop/p-/digital-product/pmp-pmi-study-hall-essentials-subscription/dp080) - [PMBOKガイドの案内](https://www.pmi.org/standards/pmbok) - [PMI CCR（資格維持）ハンドブック（PDF）](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/ccr-certification-requirements-handbook.pdf) --- # コパイロットの先へ：AIエージェントが私の日々のワークフローを変えた理由 > 賢いオートコンプリートは、ほんの始まりにすぎませんでした。ターミナルで自律的に動くAIエージェントへの移行で、ソフトウェアを作り、デバッグし、リリースするやり方が変わりました。 _Slug: ai-agents-workflow-evolution · 2026-06-29_ {/* SEO METADATA SEO Title: コパイロットの先へ：AIエージェントは私のエンジニアリングのワークフローをどう変えたか SEO Description: インライン補完（Copilot）から自律型ターミナルエージェント（Claude Code）への認知的な移行と、それが開発者の生産性にもたらす影響を探ります。 Keywords: AIエージェント, 自律型コーディングエージェント, Claude Code, GitHub Copilot, 開発者の認知負荷, ソフトウェア開発ワークフロー, ターミナルエージェントのループ Canonical URL: https://www.dailysay.me/ja/posts/ai-agents-workflow-evolution OpenGraph Title: コパイロットの先へ：AIエージェントは私のエンジニアリングのワークフローをどう変えたか OpenGraph Description: インライン補完（Copilot）から自律型ターミナルエージェント（Claude Code）への認知的な移行と、それが開発者の生産性にもたらす影響を探ります。 Twitter Title: コパイロットの先へ：AIエージェントが私の日々のワークフローを変えた理由 Twitter Description: 補完ヘルパーから、ターミナルでループを回す自律型エージェントへ。コーディングの新しいパラダイムです。 */} {/* HERO IMAGE SPECIFICATION Image Prompt: "A clean editorial illustration of a terminal command prompt with concentric circles representing automated loop execution, deep blue and teal colors, modern technical style, 16:9 aspect ratio." coverAlt: "やわらかな光に包まれたターミナルのサンドボックスの中で、自律的なコード実行ループが整然と動く様子を描いた抽象的なエディトリアル・ビジュアル。" */} 2021年にGitHub Copilotが登場したとき、それはまるで魔法のようでした。モデルがコードの次の1行を予測したり、簡単なユーティリティ関数をリアルタイムで生成したりしてくれるのは、超高速のオートコンプリートと一緒にコードを書いているような感覚でした。 でも、時間が経つにつれて、私たちは慣れていきました。そしてわかってきたのです。「コパイロット」の正体は、少し賢くなったTabキーの便利機能にすぎないと。コードの行は提案してくれても、問題は解決してくれません。構文を書き、見直し、整形するという細かな作業から、こちらはいつまでも離れられないのです。コパイロットがバグのある関数を生成したら、自分でコンパイラを走らせ、エラーを見つけ、それをコピーして、コードを書き直さなければなりません。 2026年半ばまでに、私たちは新しい時代へと移行しました。**自律型AIエージェント**の時代です。 コパイロットとエージェントの違いは、単なる能力の差ではありません。認知的な作業を委ねられるかどうか、という違いです。コパイロットは、一秒単位で見張っていなければならないアシスタントです。一方のエージェントは、ゴールを伝えれば任せられる同僚です。エージェントがバックグラウンドでループを回しているあいだ、こちらはシステムアーキテクチャに集中できます。 この記事では、こうしたワークフローの進化がなぜ私の日々の開発体験を変えたのか、そしてこの新しいワークフローを支えられるよう、自分の開発環境をどう整えればいいのかをお話しします。 --- ## オートコンプリートがもたらす認知負荷 エージェント型ワークフローの威力を理解するには、まず初期のAIコーディングツールが私たちの頭にどれだけの負担をかけていたのかを見ておく必要があります。インラインのオートコンプリートを使っていると、注意が絶えず中断されます。 ``` [コードを書く] ---> [停止：補完候補を読む] ---> [判断：採用 / 修正] ^ (フローが途切れる) ``` 数秒おきに、モデルが1行を提案してきます。そのたびに手を止め、提案を読み、正しいかどうかを判断し、受け入れ、次の行を書き、また同じことを繰り返します。この絶え間ないコンテキストスイッチが、フロー状態をむしばんでいきます。生成されたテキストをリアルタイムで細かくレビューし続ける役回りになるので、ぐったり疲れてしまうこともあります。 しかもコパイロットは、実行環境から切り離されています。自分が生成したコードが実際にビルドできるのか、テストスイートを通るのか、データベーススキーマに沿っているのかを知りません。コンパイルが通るかどうかを確かめる負担は、すべてこちら側に残ったままです。 --- ## 自律型エージェントのループ {/* INLINE IMAGE 1 SPECIFICATION Image File Name: "/images/posts/agents-evolution/agentic-loop-stages.webp" Image Prompt: "A clean software schematic showing three circular nodes: Set Goal, Agent Execution Loop, and Final Human Review, vector flat layout, minimal branding." Alt text: "開発者のエージェントループにおける3つの段階（ゴールの設定、エージェントのループ、プルリクエストのレビュー）を示す図。" Caption: "3段階のエージェント型ワークフロー：1行ずつのコーディングから、ゴール設定とコードレビューへと焦点が移る。" Position: 「自律型エージェントのループ」の後 */} 自律型コーディングエージェント（Claude Code、Devin、ターミナルで動くエージェントスクリプトなど）は、ツールを使いながらループを回すことで、この問題を解決します。 エディタの前に座ってコードが補完されていくのを眺める代わりに、もう一段高い抽象度で仕事をするようになります。 1. **ゴールを設定する**：エンジニアリングのタスクを普通の言葉で定義します（例：「APIクライアントにリトライ間隔のパラメータを追加して、テストのモックも更新して」）。 2. **エージェントのループを回す**：エージェントがコードベースを読み、テストスイートを実行し、ソースファイルを編集し、コンパイルエラーに対処しながら、目標とする条件を満たすまでループを繰り返します。 3. **差分をレビューする**：最終的なgit diffやプルリクエストをレビューします。チェックするのは、フォーマットの細部ではなくロジックです。 自律型エージェントのループがエラーをどう処理するのか、概念図で見てみましょう。 ```mermaid graph TD Goal[ゴールを定義] --> Plan[エージェントがファイル変更を計画] Plan --> Edit[コードベースを編集] Edit --> Build[ビルドコマンドを実行] Build -->|コンパイルエラー| ReadLog[コンパイラのログを読む] ReadLog --> Edit Build -->|ビルド成功| RunTest[テストスイートを実行] RunTest -->|テスト失敗| ReadTestLog[失敗したテストを読む] ReadTestLog --> Edit RunTest -->|テスト通過| Complete[完了：差分をレビュー] style Build fill:#333,stroke:#666,stroke-width:1px style RunTest fill:#333,stroke:#666,stroke-width:1px style Edit fill:#111,stroke:#666,stroke-width:2px ``` モデルがコンパイラやbashの実行環境と直接やり取りできるようにすれば、「ファイルを保存 → コンパイラの警告を読む → 型を直す → ファイルを保存」というサイクルを丸ごとエージェントに任せられます。これはソフトウェアエンジニアリングにおける地味な繰り返し作業であり、まさにモデルが得意とする仕事です。 --- ## 今日から取り入れられるエージェント型ワークフロー 日々の開発スタイルをオートコンプリートからエージェントのループへ切り替えたいなら、次の3つのステップを実践してみてください。 1. **宣言的にゴールを書く**：「このファイルを開いて、この行を変えて」のような細かい手順でエージェントに指示するのはやめましょう。代わりに、ゴールと成功の条件を伝えます。 * *例*：`"checkin APIにユーザーロールのバリデーションを追加して。src/test/auth.spec.tsのテストが通ることを確認し、npm run buildを実行して検証すること。"` 2. **すばやく回るテストスイートを用意する**：エージェントはフィードバックループが速いほど力を発揮します。テストの実行に10分かかるようでは、エージェントのループも遅くなり、トークンもかさみます。ローカルのユニットテストは高速に（5秒未満に）保ち、エージェントが編集をすぐに検証できるようにしておきましょう。 3. **クリーンな状態でコミットしておく**：エージェントをリポジトリで自由に動かす前に、ワークスペースに未コミットの変更がない状態にしておきましょう。そうすれば、エージェントがループにはまって抜け出せなくなったときは`git reset --hard`で作業を破棄できますし、`git diff`で編集内容を簡単にレビューすることもできます。 --- ## 今後の展望：エージェントネイティブなリポジトリ {/* INLINE IMAGE 2 SPECIFICATION Image File Name: "/images/posts/agents-evolution/repository-future.webp" Image Prompt: "A high-tech visualization showing an agent crawling a code repository structure, abstract neon green wireframes, dark clean layout." Alt text: "自動化されたチェックインポリシーと継続的な検証ループを備えた、エージェントネイティブなリポジトリの図。" Caption: "これからのリポジトリ構造：人間が読むことにも、エージェントが実行することにも最適化されている。" Position: 「考えが変わったきっかけ」の前 */} これからのリポジトリは、人間のためだけでなく、エージェントのためにも設計されるようになるでしょう。 そこで登場するのが、**エージェントネイティブなリポジトリ**です。こうしたコードベースには、AIエージェント専用の構造化された設定マップ（高度な`agents.config.json`ファイルや、標準化されたMCPサーバーなど）が含まれ、コードベースのアーキテクチャ、モジュールごとの責務、ビルドスクリプト、テスト対象を説明してくれます。 エンジニアが新しく加わったメンバーにコードベースの構成を説明する代わりに、設定マニフェストが、新しくやって来たエージェントに、システムの中をどう進み、どうビルドし、どう拡張すればいいのかを正確に教えてくれるようになるのです。 --- ## 関連記事 - ターミナル型エージェントとビジュアルエディタの詳しい比較は、[Claude Code vs Cursor：作り手目線の徹底比較](/ja/posts/claude-code-vs-cursor)をどうぞ。 - エージェントとコードベースのコンテキストをつなぐ標準プロトコルについては、[MCPはAIアプリケーションのUSB-Cになる](/ja/posts/mcp-usb-c-of-ai-applications)で解説しています。 - 自律的なコードループを使いながら品質と基準を保つためのルールは、[AIでコード品質を保つための原則](/ja/posts/principles-of-maintaining-code-quality-with-ai)を読んでみてください。 ## 参考リンク - 自律型エージェントのループや研究ベンチマークについては、[OpenAI Research Blog](https://openai.com/research)で読めます。 - ターミナルツールやエージェントの設定は、[GitHub Developer Docs](https://developer.github.com/)で調べられます。 - 状態管理やパイプライン実行のループについては、[Anthropic Developer Portal](https://docs.anthropic.com/)を参照してください。 --- ## 考えが変わったきっかけ 何年ものあいだ、私は「コードを書く」という職人技を擁護してきました。メカニカルキーボードで構文を打ち込む手触り、変数を調整する感覚、エディタが構文をハイライトしていく様子。そのすべてに誇りを持っていました。コードの実行をエージェントに任せたら、自分はコードベースから切り離され、怠惰な作り手になってしまう。そう思っていたのです。 そんなとき、レガシーなコードベース全体で、30個のAPIエンドポイントを新しいテナントIDパラメータに対応させる必要が出てきました。繰り返しばかりの、退屈な作業です。 私は`claude`を起動してゴールを伝え、コーヒーを取りに行きました。 3分後に戻ってくると、エージェントの作業はもう終わっていました。`git diff`を実行して変更を確認すると、エージェントは32個のファイルを修正し、ルートのパラメータを更新し、データベースのクエリを調整し、エンドポイントごとにモックテストを追加していました。コードは一行残らずフォーマットされ、型も正しく、コンパイルが通ることも確認済みでした。 そこで気づいたのです。**タイピングへの誇りは、摩擦への執着にすぎなかった**のだと。本当のエンジニアリングは、行を打ち込むことの中にはありませんでした。テナント分離をサポートするという、アーキテクチャ上の選択の中にあったのです。実装の細部をエージェントに任せたことで、何時間分もの単調なキーボード作業を省き、システム設計に集中し続けられました。私はコードを打つのをやめ、エージェントに指示を出す側に回ったのです。 --- # AI時代のスピード：数週間で3つのプロダクトをつくった方法 > かつてソフトウェアプロダクトのローンチには、何か月もの開発が必要でした。AIを使って、3つのデジタルプロダクトを数週間で設計・開発・リリースした方法を紹介します。 _Slug: how-i-built-three-products-faster-with-ai · 2026-06-18_ {/* SEO METADATA SEO Title: AI時代のスピード：AIで3つのプロダクトを数週間でつくる SEO Description: AIコードツールを使って、1か月足らずで3つのSaaS MVPを開発・ローンチしたステップごとのケーススタディ。ワークフローとアーキテクチャを紹介します。 Keywords: 個人開発, AIで開発, AIソフトウェア開発, Next.js Supabase MVP, ラピッドプロトタイピング, AI開発者体験 Canonical URL: https://www.dailysay.me/ja/posts/how-i-built-three-products-faster-with-ai OpenGraph Title: AI時代のスピード：AIで3つのプロダクトを数週間でつくる OpenGraph Description: AIコードツールを使って、1か月足らずで3つのSaaS MVPを開発・ローンチしたステップごとのケーススタディ。ワークフローとアーキテクチャを紹介します。 Twitter Title: AI時代のスピード：数週間で3つのプロダクトをつくった方法 Twitter Description: 遅いコーディングから、AIによる高速プロトタイピングへ。数週間で3つのプロダクトをリリースした振り返り。 */} {/* HERO IMAGE SPECIFICATION Image Prompt: "A minimal digital layout showing three clean web browser mockups showcasing different UI features, dark theme background, modern product design style, 16:9 aspect ratio." coverAlt: "別々のWebアプリケーションを表す3つのすっきりしたUIダッシュボードを積み重ね、その上にコーディングツールを配したモダンなフラットデザイン" */} 長いあいだ、プロダクトのアイデアから本番ローンチまでの道のりはマラソンのようなものでした。個人開発者なら、ソフトウェアプロダクトをつくるには、何週間もかかるボイラープレートのセットアップを覚悟しなければなりませんでした。データベースの設定、認証の構築、APIルーティングのエンドポイントづくり、レスポンシブなレイアウトの作成、そしてバリデーション用スクリプトの作成です。 プロダクト独自の価値の核となる部分をようやくコーディングする段階にたどり着くころには、もうへとへとになっていたのです。 でも2026年半ばの今、ものをつくるスピードは根本から変わりました。私は4週間で、3つのまったく異なるWebアプリケーションを設計・開発・リリースしました。 1. **SentryPost**：オーディエンスのエンゲージメントログをもとに配信時刻を最適化する、SNSの自動予約投稿ツール。 2. **Tabulate**：PDFのレシートを解析し、項目を構造化された経費シートに直接マッピングするデータベースユーティリティ。 3. **DailyList**：毎日届くメールのアップデートを1つのダッシュボードに要約する、ミニマルなニュースレターアグリゲーター。 私は10xエンジニアではありませんし、週100時間働いてこれらのソフトウェアを書いたわけでもありません。そのかわりに、標準化したスタック（Next.js、TailwindCSS、Supabase）を使い、ボイラープレート、レイアウト、連携ロジックをまるごとAIコーディングエージェントに任せたのです。 ここでは、思考のスピードでものをつくるなかで学んだワークフロー、アーキテクチャ、そして開発者としての教訓を振り返ります。 --- ## 標準化されたスタック：スピードのための設計図 AIで速くつくるには、アーキテクチャのばらつきをなくさなければなりません。プロジェクトごとにデータベースのプロバイダーやバックエンドのフレームワーク、CSSのアプローチを変えていると、AIコーディングエージェントが混乱します。規約がごちゃまぜになり、コンパイルエラーが一気に増えてしまうのです。 私は3つのプロダクトすべてで、ひとつのシンプルなスタックに統一しました。 * **フレームワーク**：Next.js（App Router、TypeScript） * **スタイリング**：TailwindCSS（ユーティリティクラスですばやくレイアウトを組むため） * **データベースと認証**：Supabase（メール認証が組み込まれたPostgreSQL） * **デプロイ**：Vercel（プレビューデプロイを自動化するため） ``` +-------------------------------------------------+ | Next.js App Router (TypeScript) | | | | [Frontend UI: Tailwind] <--> [Backend API] | | | | | (Supabase Client) | | v | | [Supabase DB / | | Authentication] | +-------------------------------------------------+ ``` スタックを同じにしておいたことで、モデルのコンテキストはすべてのプロジェクトでぶれずにそろっていました。データベースのスキーマ、クライアントのラッパー、認証ガードを、リポジトリをまたいで再利用できたのです。新しいプロジェクトのターミナルを立ち上げて「Supabase認証のクライアントラッパーをセットアップして」と頼むと、AIは以前のコードベースの規約にぴったり合ったラッパーを生成してくれました。 --- ## ステージ1：スキーマの下書きとデータベースのセットアップ {/* INLINE IMAGE 1 SPECIFICATION Image File Name: "/images/posts/three-products/database-migration.webp" Image Prompt: "A clean database ER diagram showing table structures for users, posts, and metrics connected by clean vector lines, high-tech dark interface style." Alt text: "顧客のサブスクリプション、タスクキュー、ユーザー指標のリレーショナルデータベーススキーマを示す図" Caption: "リレーショナルデータベースの構造化：Markdownの表をAIエージェントに渡して、Postgresのマイグレーションを生成する" Position: 「ステージ1：スキーマの下書きとデータベースのセットアップ」の直後 */} アプリをローンチするうえで最初のボトルネックになるのは、データベース設計です。UIを書く前に、テーブル、キー、外部キーによるリレーションを定義しなければなりません。 私はSQLを手で書くかわりに、シンプルなMarkdownの表でデータベーススキーマを設計しました。たとえば**SentryPost**では、次のような記述を下書きしました。 ```markdown テーブル: - users: id (uuid), email (text), tier (text) - schedules: id (uuid), user_id (ref users), title (text), content (text), send_at (timestamp), status (enum) - metrics: id (uuid), schedule_id (ref schedules), impressions (int), clicks (int) ``` この表をターミナルのエージェントに渡して、次のクエリを実行しました。 `claude -p "このスキーマ定義に合わせて、Supabase用のPostgreSQLマイグレーションスクリプトを生成して。ユーザーが自分のデータだけを読み書きできる行レベルセキュリティ（RLS）ポリシーも含めること。"` 数秒のうちに、エージェントはマイグレーション用のSQLを生成しました。 ```sql -- schedulesテーブルを作成 CREATE TYPE schedule_status AS ENUM ('draft', 'scheduled', 'sent', 'failed'); CREATE TABLE public.schedules ( id UUID DEFAULT gen_random_uuid() PRIMARY KEY, user_id UUID REFERENCES auth.users(id) ON DELETE CASCADE NOT NULL, title TEXT NOT NULL, content TEXT NOT NULL, send_at TIMESTAMP WITH TIME ZONE NOT NULL, status schedule_status DEFAULT 'draft'::schedule_status NOT NULL, created_at TIMESTAMP WITH TIME ZONE DEFAULT timezone('utc'::text, now()) NOT NULL ); -- 行レベルセキュリティを有効化 ALTER TABLE public.schedules ENABLE ROW LEVEL SECURITY; -- SELECT用のポリシーを作成 CREATE POLICY "Users can view their own schedules" ON public.schedules FOR SELECT USING (auth.uid() = user_id); -- INSERT用のポリシーを作成 CREATE POLICY "Users can insert their own schedules" ON public.schedules FOR INSERT WITH CHECK (auth.uid() = user_id); ``` マイグレーションファイルとRLSポリシーを1つのプロンプトで生成したことで、手作業でSQLを書く何時間もの手間を省けました。RLSは構文エラーを出さずに手で書くのが難しいことで有名ですが、何千ものSupabaseの設定を学習しているAIは、ポリシーを正しく扱ってくれました。 --- ## ステージ2：TailwindとFlexboxでUIをすばやくデザインする {/* INLINE IMAGE 2 SPECIFICATION Image File Name: "/images/posts/three-products/layout-generation.webp" Image Prompt: "A digital layout mockup displaying a modern SaaS user dashboard with clean grid modules, soft neon green highlights, minimal vector design." Alt text: "すっきりしたサイドバーナビゲーション、指標のグリッド、タスクのリストを表示するUIモックアップ" Caption: "UIのプロトタイピング：AIエージェントを使い、Tailwindのクラスで直接レスポンシブなダッシュボードを組み立てる" Position: 「ステージ2：TailwindとFlexboxでUIをすばやくデザインする」の直後 */} データベースの準備ができたら、次はユーザーインターフェースです。レイアウトをゼロからデザインするのは時間のかかる作業です。flex-wrapやpaddingの比率、ダークモード用のクラスを調整するとなると、なおさらです。 私は「レイアウトの下書き」というアプローチをとりました。インターフェースのレイアウトを、意味ベースで記述したのです。 ``` SentryPostのダッシュボードのシェルレイアウトをつくって。 - サイドバー：ナビゲーション項目（Dashboard、Schedules、Analytics、Settings）。下部にプロフィールカード。 - メインエリア：パンくずリストと「Create New」ボタンのあるヘッダー。 - グリッド：3つの指標カード（Scheduled Posts、Sent Posts、Success Rate %）。 - リスト：予約済みの投稿をステータスバッジ付きで表示する、すっきりしたデータリスト。 ``` このレイアウトの依頼をAIに渡すと、Tailwindのレイアウト構造を含む、よく最適化されたReactコンポーネントが返ってきました。CSSクラスを*どう*書くかではなく、画面に*何を*表示すべきかを記述することで、レイアウトの調整はAIに任せられたのです。 ボタンの配置がおかしく見えても、CSSのflexboxのルールを調べたりはしませんでした。エディタでそのブロックを選択して、「このボタンをカードの右端に寄せて、縦方向は中央、隣の入力欄と高さをそろえて」と頼むだけです。AIはTailwindのユーティリティクラスを即座に書き換えてくれました。 --- ## すばやくつくるための実践戦略 このスピードでプロダクトをつくってローンチしたいなら、開発の習慣を変える必要があります。 * **ボイラープレート用のリポジトリを使う**：プロジェクトのたびに`create-next-app`をゼロから実行するのはやめましょう。Supabase認証のクライアント設定、標準的なナビゲーションコンポーネント、決済用のフック、メタデータのレイアウトが最初から組み込まれた、非公開のテンプレートリポジトリを用意しておきます。 * **データベース操作は早めにテストする**：UIを書く前に、ダミーのレコードを挿入・読み出しするローカルスクリプトを書きます。見た目のフォームをつくる前に、データベースの制約、スキーマ、APIルートが動くことを確認しておきましょう。 * **過剰設計を避ける**：MVPに複雑なキャッシュやキューシステム、スケーラブルなクラスターを実装してはいけません。顧客の需要を検証できるまでは、基本的なSQLトリガー、シンプルなcronジョブ、データベースのふつうの行をキューの保存に使えば十分です。 * **フィーチャーフラグで反復する**：仕上げるのが難しい機能は、フィーチャーフラグで包むか、UIのリンクを無効にしておきます。まずはコアとなるループを出すことに集中しましょう。 --- ## これからの展望：ソロプレナーのスタートアップ {/* INLINE IMAGE 3 SPECIFICATION Image File Name: "/images/posts/three-products/solopreneur-future.webp" Image Prompt: "A modern workspace where a single builder collaborates with virtual AI team avatars shown on screens, editorial digital design, premium dark colors." Alt text: "ひとりの創業者が、AIエージェントによるバーチャルチームを取りまとめるモダンなワークスペースの図" Caption: "これからのソロプレナー：コーダーから、AIによるバーチャルなエンジニアリングチームを率いるゼネラルマネージャーへ" Position: 「私の考えが変わったきっかけ」の直前 */} これから先、ソフトウェア開発のコストはゼロに近づき続けるでしょう。 システムアーキテクチャと顧客ニーズを理解しているひとりの開発者が、以前ならベンチャーキャピタルの出資を受けたスタートアップが必要だったようなWebアプリケーションのポートフォリオを、つくって運営できるようになります。テック業界の競争優位は、*コーディングの能力*から、*市場への洞察、顧客による検証、そして販売チャネル*へと移っていきます。 未来に成功する開発者は、手書きでいちばんきれいなコードループを書く人ではありません。問題を見つけ、システムを設計し、AIエージェントを指揮して、安定したソリューションを記録的な速さでつくれる人です。 --- ## 関連記事 - ターミナルネイティブなエージェントツールが複数ファイルの更新をどう速くするのかは、[Claude Code vs Cursor：作り手目線の徹底比較](/ja/posts/claude-code-vs-cursor)をご覧ください。 - データベースやAPIのアダプターを標準化する方法は、[MCPはAIアプリケーションのUSB-Cになる](/ja/posts/mcp-usb-c-of-ai-applications)で紹介しています。 - 速いペースで開発しながらもリポジトリのコードをきれいに保ち、コンパイル時のバグを避けたいなら、[AIでコード品質を保つための原則](/ja/posts/principles-of-maintaining-code-quality-with-ai)を読んでみてください。 ## 参考リンク - データベースのセットアップやRLSのガイドラインは、[Supabase Documentation Blog](https://supabase.com/blog)で確認できます。 - ページレイアウトやデプロイの最適化については、[Vercel Blog](https://vercel.com/blog)が参考になります。 - ラピッドプロトタイピングとソフトウェア開発のスピードについては、[GitHub Blog](https://github.blog/)で読めます。 --- ## 私の考えが変わったきっかけ 以前の私は、ソフトウェアの会社を始めるには、共同創業者とシードラウンドの資金調達、そして何か月にもわたる開発のイテレーションが必要だと信じていました。2023年はまるまる1年、あるSaaSのアイデアの設計ドキュメントを書き、フレームワークについて議論し、実際のユーザーがひとりも触れることのなかったローカルのデータベースモデルを最適化することに費やしました。実行の複雑さに、身動きがとれなくなっていたのです。 4週間の実験を始めるとき、私はあらかじめ構成済みのスタックだけでつくり、コードはコーディングエージェントに書かせると決めました。そして、たとえ設定ページが空っぽでも、コアとなるユーザーの導線が動いた時点で、それぞれのアプリを半ば強制的にローンチすることにしたのです。 開発からわずか6日で最初のプロダクトがVercel上で公開されるのを見て、私の世界観はまるごと変わりました。実際のユーザーが登録し、フィードバックを送り、機能をリクエストしはじめたのです。 私は気づきました。**エディタで書くコードは実装の細部にすぎず、価値はユーザーのフィードバックとプロダクトの更新のあいだを回るループにある**のだと。実行の細部をAIに任せたことで、私はエディタのフォーマッターのように振る舞うのをやめ、プロダクトオーナーとして動けるようになりました。この1か月で、それまでの2年間よりも多くのコードをリリースし、人生で初めて、リアルタイムでものをつくっている実感を得ました。 --- # Claude Code vs Cursor：作り手目線の徹底比較 > 両方を使って何か月も実際のソフトウェアを作ってきた経験から、ターミナルネイティブなClaude CodeとIDEネイティブなCursorの違いを詳しく解説します。 _Slug: claude-code-vs-cursor · 2026-06-06_ {/* SEO METADATA SEO Title: Claude Code vs Cursor：開発者のための実践比較 SEO Description: AnthropicのClaude Code CLIと、VS CodeフォークのCursorを徹底比較。エージェント型の開発ワークフローにはどちらのツールが最適なのかを解説します。 Keywords: Claude Code, Cursor, AIコードエディタ, エージェント型コーディング, 開発者体験, VS Code AI, ターミナルエージェント Canonical URL: https://www.dailysay.me/ja/posts/claude-code-vs-cursor OpenGraph Title: Claude Code vs Cursor：開発者のための実践比較 OpenGraph Description: AnthropicのClaude Code CLIと、VS CodeフォークのCursorを徹底比較。エージェント型の開発ワークフローにはどちらのツールが最適なのかを解説します。 Twitter Title: Claude Code vs Cursor：作り手目線の徹底比較 Twitter Description: ターミナルネイティブなCLIか、IDEネイティブなエディタか。勝つのはどちらのAIコーディングツール？ */} {/* HERO IMAGE SPECIFICATION Image Prompt: "A clean split screen layout showing glowing terminal commands on one side and a modern code editor workspace on the other, dark tech style, minimal icons, 16:9 aspect ratio." coverAlt: "左にコマンドラインの出力が表示されたターミナル、右に高機能なモダンIDEのエディタを並べた、ダークテーマの分割画面グラフィック。" */} この1年、AI支援開発の王者といえば、文句なしにCursorでした。VS CodeのフォークとしてLLMをテキストエディタに直接組み込み、インライン補完（Tab）、チャットオーバーレイ（Cmd+K）、コードベース全体のインデックス化（@Codebase）を広めました。何千人もの開発者の、日々のソフトウェアの書き方を変えたツールです。 ところが2025年初め、AnthropicがClaude Codeを発表し、開発者の世界に揺さぶりをかけました。Claude Codeは、エディタの中に住むのではなく、シェル上で直接動く、ターミナルネイティブなCLIエージェントです。 サイドパネルにプロンプトを打ち込んで「Apply」をクリックする代わりに、ターミナルでClaude Codeを起動します。するとClaude Codeが自律的にファイルを検索し、bashコマンドを実行し、テストを走らせ、ビルドログを読み、リポジトリを更新してくれます。 私はこの2つのツールを使って、まったく異なる3つのプロダクトを作り、リリースしてきました。だからこそ、マーケティングの誇大宣伝からは一歩離れた話をしたいと思います。この2つは、同じ基盤モデルに別々のインターフェースをかぶせただけのものではありません。開発者体験（DX）についての、根本的に異なる2つの思想を体現しているのです。 ここからは、ターミナルネイティブなエージェント型コーディングと、エディタネイティブなインターフェース型の支援ツールを、実際に使った立場から比べていきます。 --- ## アーキテクチャの分かれ目：IDEネイティブ vs ターミナルネイティブ CursorとClaude Codeの違いを理解するには、それぞれがワークスペースとどう関わっているのかを見る必要があります。 ### Cursor：エディタファーストのアプローチ Cursorは、エディタの延長として機能します。*コードを書いている最中に*手助けするよう設計されていて、主に開いているドキュメントとファイルツリーの中で動作します。 ``` +------------------------------------+ | Cursor IDE | | | | [File Tree] [Active Editor] | <--- インライン補完、Tab、Cmd+K | [Side Panel Chat] | <--- ファイルをまたいだ意味的コンテキスト +------------------------------------+ ``` Cursorは視覚的にとてもリッチです。差分の表示が得意で、変更を受け入れる前に1行ずつレビューできます。ただし、根本的にはIDEのサンドボックスのルールに縛られています。Cursorがコマンドを実行したりテストスイートを検証したりしたいときは、あなたがターミナルパネルを開いて、自分でスクリプトを実行するしかありません。 ### Claude Code：シェルファーストのアプローチ Claude Codeは、シェルの中に住んでいます。ローカルのファイルシステムを直接読み書きでき、bashコマンドも実行できる自律型エージェントとして動作します。 ``` +------------------------------------+ | System Terminal | | | | $ claude | | > "Find the broken test and fix it"| | [Agent Loop] | | 1. grep search files | | 2. rewrite lines | | 3. run `npm test` | <--- コマンドを直接実行 | 4. verify success / loop | +------------------------------------+ ``` Claude Codeはターミナルの中で動くので、ツールの呼び出しを自律的につなげていけます。たとえば「このTypeScriptワークスペースのコンパイルエラーを直して」と頼むと、まずビルドスクリプトを実行し、ターミナルに出たエラー出力を読み、問題のあるファイルに移動して編集し、もう一度ビルドスクリプトを実行します。そしてビルドが成功するまで、このループを繰り返します。 --- ## 機能別の直接比較 {/* INLINE IMAGE 1 SPECIFICATION Image File Name: "/images/posts/claude-vs-cursor/headless-agent-flow.webp" Image Prompt: "A diagram showing an agent loop running tests, checking errors, editing files, and git committing, clean vector art, dark design, cyan lines." Alt text: "ターミナルエージェントのループを示す図：ターミナル出力を読む → コードを編集 → シェルスクリプトを実行 → 結果を検証。" Caption: "Claude Codeの自律型エージェントループ：ターミナルネイティブなツールだからこそ自己修正ができる。" Position: 「機能別の直接比較」の後 */} どちらをいつ使うべきかを判断するために、具体的なエンジニアリングタスクごとに、それぞれの実力を見ていきましょう。 ### 1. コードベースの検索とナビゲーション * **Cursor**：`@Codebase`機能は、ベクトル検索の埋め込みを使い、意味的な類似度にもとづいて関連ファイルを取り出します。「セッションストレージはどこで扱っている？」のような大まかな質問をして、そのファイルに直接ジャンプするのにぴったりです。 * **Claude Code**：シェルの中で、`grep`や`find`、ファイルの直接読み込みといった昔ながらのファイルシステムツールを使います。ベクトル検索はありませんが、その場でgrepのクエリを自在に組み立てられるので、驚くほど正確です。コマンドラインユーティリティを使いこなす、経験豊富なLinux開発者のように振る舞います。 ### 2. 複数ファイルにまたがるリファクタリング 典型的なリファクタリングのタスクを見てみましょう。15個のファイルで使われているコンポーネントの中で、propの名前を変更するというものです。 * **Cursor**：VS Code組み込みのシンボルのリファクタリング機能を使うか、Composer（Cmd+I）を開いてファイルの更新を頼みます。Composerがファイル変更の一覧を出力するので、それをレビューして「Save All」をクリックするか、差分を一つずつ受け入れる必要があります。 * **Claude Code**：ターミナルで直接頼むだけです。`claude -p "checkoutコンポーネントのbillingAddress propをaddressにリネームして、呼び出し箇所もすべて更新して。"` 裏側では、Claude Codeが次のような構造化されたループを実行しています。 1. `grep`を使って、`billingAddress`の出現箇所をすべて検索します。 2. 影響を受ける各ファイルを読み込みます。 3. 検索・置換ツールを使って、コードを書き換えます。 4. `npm run typecheck`を実行し、コンパイルエラーがないことを確認します。 5. 型チェックが失敗したら、コンパイラのログを読んで残りの箇所を修正し、もう一度型チェックを実行します。 ターミナルに表示されるツールログは、たとえばこんな感じです。 ```bash $ claude ? What would you like to do? propのリネーム後に出たTypeScriptの型エラーを直して。 Thinking... 1. Executing command: npm run typecheck 2. Command output: src/components/checkout/Review.tsx:42:15 - error TS2339: Property 'billingAddress' does not exist on type 'CheckoutProps'. 3. Reading file: src/components/checkout/Review.tsx 4. Replacing file content in src/components/checkout/Review.tsx (lines 40-45) 5. Executing command: npm run typecheck 6. Command output: ✓ Success. Typecheck complete. Review.tsxに残っていた'billingAddress'の参照を見つけて更新しました。型チェックは通るようになりました。 ``` --- ## 使い分けのための実践フレームワーク 生産性を最大化したいなら、どちらか一方のツールを選んで、もう一方を捨てるべきではありません。開発パイプラインの中で、互いを補い合うシステムとして使いましょう。 | タスク／シナリオ | おすすめのツール | 理由 | |---|---|---| | **機能のたたき台作りとレイアウト** | **Cursor** | 新しいコードブロックを書いたり、CSSのスタイルを調整したり、編集内容をビジュアルにプレビューしたりするのに最適。 | | **コンパイルエラー／テスト失敗のデバッグ** | **Claude Code** | ビルドやテストのスクリプトを自律的に実行し、stdoutを確認して自己修正できるので最適。 | | **コードベース全体のリファクタリング** | **Claude Code** | UIのもたつきなしに、ファイルをまたいでヘッドレスな検索・置換のコマンドループを回せるので最適。 | | **Gitのレビューとコミット** | **Claude Code** | git CLIにネイティブにアクセスでき、`git diff`を実行して、的確なコミットメッセージを書けるので最適。 | --- ## 今後の展望：エージェントのサンドボックスとしてのターミナル {/* INLINE IMAGE 2 SPECIFICATION Image File Name: "/images/posts/claude-vs-cursor/agentic-dx.webp" Image Prompt: "A sleek conceptual visual showing an agent executing tasks inside a secure containerized shell, modern editorial art, teal and violet highlights." Alt text: "ターミナルエージェントがアプリケーションをコンパイルし、テストし、デプロイする、自律的な開発サンドボックスの図。" Caption: "これからの開発サンドボックス：AIエージェントがローカルのファイルとコンパイラを直接操作する。" Position: 「考えが変わったきっかけ」の前 */} これからのコーディングツールは、手動の「コパイロット」型の仕組みから離れていくでしょう。画面上でテキストが補完されていくのを眺める時間は減っていきます。 その代わりに、AIコーディングアシスタントとの主なインターフェースは、エージェント型のサンドボックスになります。コンテナ化されたCLIエージェントを起動し、ゴールを定義して（例：「ダッシュボードページに請求履歴のテーブルを追加して」）、あとはバックグラウンドでエージェントに作業してもらうのです。エージェントはコードを書き、コンパイラを実行し、テストカバレッジを確認し、アセットをビルドして、レビュー用のブランチをプッシュします。 人間の開発者としての私たちの役割は、*コードを一行ずつ書くこと*から、*制約を検証し、プルリクエストをレビューすること*へと移っていくでしょう。 --- ## 関連記事 - MCPのような標準化されたコンテキストプロトコルが、ターミナルネイティブなエージェントをどう支えているのかは、[MCPはAIアプリケーションのUSB-Cになる](/ja/posts/mcp-usb-c-of-ai-applications)で解説しています。 - 自律型ツールを使いながらリポジトリの基準を守るためのガイドは、[AIでコード品質を保つための原則](/ja/posts/principles-of-maintaining-code-quality-with-ai)をご覧ください。 - 開発者がエディタの外で独自の自動化スクリプトをどう活用できるのかは、[すべてのPMがAI自動化を学ぶべき理由](/ja/posts/every-pm-should-learn-ai-automation)で紹介しています。 ## 参考リンク - CLIの公式リリース情報と開発者向けガイドラインは、[Anthropic Claude Code Docs](https://docs.anthropic.com/en/docs/agents-and-tools/claude-code)で確認できます。 - IDEの機能やコードベースのインデックス設定については、[Cursor公式サイト](https://www.cursor.com/)をチェックしてみてください。 - 開発者体験のトレンドやモダンなコーディングパイプラインについては、[OpenAI Blog](https://openai.com/blog)も参考になります。 --- ## 考えが変わったきっかけ Claude Codeのことを初めて聞いたとき、私は懐疑的でした。「Cursorのサイドパネルのチャットとビジュアルな差分があるのに、なんでわざわざターミナルのツールを使うんだ？」と思ったのです。せっかく高度なIDEのラッパーまで作り上げてきたのに、コマンドラインインターフェースに逆戻りするように感じました。 そんなある日、複数のパッケージからなるモノレポで、複雑なキャッシュのバグを直さなければならなくなりました。CursorのComposerを使ってみたものの、ループにはまり続けました。Composerがファイルを修正すると、私がターミナルを開いてコンパイルし、TypeScriptのエラーを確認し、そのエラーをチャットにコピーして戻し、直してもらう。これをひたすら繰り返すのです。コンテキストの切り替えは遅く、もどかしいばかりでした。 私はターミナルを開いて`claude`をインストールし、キャッシュのバグを直すように頼みました。 ターミナルの画面がコマンドで埋まっていくのを眺めていました。Claude Codeはローカルの開発ビルドを実行し、stdoutに出たキャッシュのエラーを読み、Redisのユーティリティファイル群をgrepで検索し、ファイルを編集して、もう一度ビルドしました。TypeScriptの型の警告が出ると型定義ファイルを編集し、再び型チェックを実行して、見事に問題を解決したのです。ここまで90秒もかからず、私は一度もキーボードに触れていません。 その瞬間、私は気づきました。**複雑なエンジニアリングのタスクでは、ビジュアルエディタはボトルネックになる**のだと。エージェントに必要なのは、テキストウィンドウやビジュアルなツリーではありません。コンパイラと、ターミナルと、シェルのループです。ターミナルは後退ではありません。自律的なシステムにとって究極のサンドボックスなのです。 --- # すべてのPMがAI自動化を学ぶべき理由 > プロダクトマネジメントは、調整業務の多さで知られる仕事です。軽量なAI自動化パイプラインを自分で組めば、PMは集中できる時間を取り戻し、より良いプロダクトをつくれます。 _Slug: every-pm-should-learn-ai-automation · 2026-05-27_ {/* SEO METADATA SEO Title: すべてのPMがAI自動化と独自パイプラインを学ぶべき理由 SEO Description: プロダクトマネージャーがAI自動化パイプラインを使ってユーザーフィードバックの仕分け、Jiraチケット、仕様書づくりを自動化し、プロダクト戦略に集中する方法を紹介します。 Keywords: プロダクトマネジメント, AI自動化, プロダクトマネージャーの業務フロー, PM向けAIエージェント, n8n LLM, 開発者との協業 Canonical URL: https://www.dailysay.me/ja/posts/every-pm-should-learn-ai-automation OpenGraph Title: すべてのPMがAI自動化と独自パイプラインを学ぶべき理由 OpenGraph Description: プロダクトマネージャーがAI自動化パイプラインを使ってユーザーフィードバックの仕分け、Jiraチケット、仕様書づくりを自動化し、プロダクト戦略に集中する方法を紹介します。 Twitter Title: すべてのPMがAI自動化を学ぶべき理由 Twitter Description: PMが独自のLLM自動化で事務作業のオーバーヘッドをなくす方法。 */} {/* HERO IMAGE SPECIFICATION Image Prompt: "A clean, modern editorial layout showing user reviews feeding into automatic classification blocks, which cleanly map into a developer task board, technical aesthetic, purple and gray tone, 16:9 aspect ratio." coverAlt: "軽量なAIエージェントが、届いたフィードバックを自動で分類・優先順位づけし、開発者向けチケットに紐づけていくダッシュボードを見るプロダクトマネージャー" */} プロダクトマネージャーとしてのあなたの価値は、意思決定の質と、チームの足並みをそろえる力で測られます。ところが自分のカレンダーを振り返ってみると、1日の大半が調整業務に消えていることに気づくはずです。顧客フィードバックの仕分け、詳細なユーザーストーリーの作成、進捗報告の取りまとめ、Jiraのバックログ整理、そして仕様書の体裁づくり。 私たちは、組織の中の「人間ルーター」になってしまいました。Slackからテキストをコピーし、Jiraに貼り付け、エンジニア向けに要約し、それをまたビジネス側に報告する。 2026年初頭の時点で、こうした事務的な負担はもはや必要悪ではなくなっています。LLMのAPIや最新の自動化プラットフォームが成熟したことで、これらの作業を自律的にこなすカスタムAIパイプラインを組めるようになったのです。 自分でAI自動化を組めるようになったPMが手にするのは、時間の節約だけではありません。AIの仕組みへの理解が深まり、開発者との協業がスムーズになり、エネルギーを深いプロダクト戦略へと振り向け直せるようになります。 --- ## PMの仕事にのしかかる手作業の負担 AI自動化がどれほどのレバレッジになるのかを理解するために、よくある場面を見てみましょう。ユーザーフィードバックの処理です。あなたのアプリに、App Storeのレビュー、カスタマーサポートのチケット、直接のフィードバックアンケートを通じて、1日200件のフィードバックが届くとします。 理想を言えば、PMはすべてのフィードバックを読み、機能ごとのバケットに分類し、優先順位をつけ、既存のチケットに紐づけるべきです。でも現実には、こうなります。 ``` [ユーザーフィードバック] --> [Slackチャンネル] | （PMは手が回らない） | v [忘れられた／未解決のフィードバック] ``` PMは忙しいので、フィードバックは放置されるか、声の大きい一部の顧客の不満だけが優先されてしまいます。チームは貴重なユーザーのシグナルを失い、プロダクトの意思決定は構造化されたデータではなく勘に頼ることになります。 これは典型的な、ルーティングと処理のボトルネックです。人間の創造性は必要ありませんが、意味を理解する力は必要です。だからこそ、AI自動化にうってつけの対象なのです。 --- ## フィードバックを仕分けるパイプラインをつくる {/* INLINE IMAGE 1 SPECIFICATION Image File Name: "/images/posts/pm-automation/feedback-triage-pipeline.webp" Image Prompt: "A clean layout showing support tickets passing through a logical model blocks with labels like Classify, Extract Metadata, Slack Alert, vector design, modern tech colors." Alt text: "ユーザーサポートのテキストを、バグのデータベースと機能ロードマップに振り分ける自動フィードバックパイプラインの図" Caption: "ユーザーフィードバックを、特定のデータベースやチャットの送り先に振り分ける自動化パイプライン" Position: 「フィードバックを仕分けるパイプラインをつくる」の直後 */} エンジニアがフィードバックの分析ツールをつくってくれるのを待つ必要はありません。PMなら、ツール連携や簡単なスクリプトを使って、午後のうちに自分でつくれます。 典型的なフィードバック仕分けパイプラインは、次のように動きます。 1. **トリガー**：新しいフィードバックが、APIのWebhook経由で届きます（例：TypeformやサポートツールのAPI）。 2. **分析**：届いたままのフィードバックを、構造化スキーマを指定したリクエストとしてLLMのエンドポイントに送ります。モデルはフィードバックを分類し、ユーザーの感情のトーンを抽出し、問題の核心を要約します。 3. **ルーティング**： - カテゴリが**バグ**なら、パイプラインが自動でJiraチケットを作成し、エンジニアチームのSlackチャンネルに通知を送ります。 - カテゴリが**機能要望**なら、そのエントリーをNotionのロードマップ用データベースに追加し、該当するプロダクト領域に紐づけます。 - 感情が**怒り**なら、カスタマーサクセスマネージャーにすぐ通知します。 では、分析ロジックをPythonで書くのがどれほど簡単か見てみましょう。構造化されたスクリプトを使えば、フィードバックのテキストを解析して振り分けられます。 ```python import os import json from openai import OpenAI from pydantic import BaseModel, Field # 1. 分類したフィードバックの構造を定義する class FeedbackAnalysis(BaseModel): category: str = Field(description="One of: bug, UI_improvement, billing, feature_request, general") summary: str = Field(description="A concise one-sentence summary of the user's problem in English") sentiment: str = Field(description="One of: positive, neutral, frustrated, angry") affected_feature: str = Field(description="The name of the feature or product area mentioned (e.g., checkout, login)") # OpenAIクライアントを初期化する client = OpenAI(api_key=os.environ.get("OPENAI_API_KEY")) def analyze_user_feedback(feedback_text: str) -> FeedbackAnalysis: # 構造化出力を使ってモデルに問い合わせる response = client.beta.chat.completions.parse( model="gpt-4o-mini", messages=[ {"role": "system", "content": "You are a customer feedback analyzer for a SaaS product."}, {"role": "user", "content": feedback_text} ], response_format=FeedbackAnalysis ) return response.choices[0].message.parsed # 使用例 sample_feedback = "I tried to upgrade my plan using my credit card, but the checkout form kept throwing a validation error on the zip code field. Extremely annoying." analysis = analyze_user_feedback(sample_feedback) print(json.dumps(analysis.dict(), indent=2)) # 出力: # { # "category": "bug", # "summary": "Checkout form fails card validation due to zip code field validation error.", # "sentiment": "frustrated", # "affected_feature": "checkout" # } ``` このスクリプトをシンプルなサーバーレス関数や自動化ツールで動かせば、顧客の声を振り分ける独自のシステムのできあがりです。もうレビューの仕分けに何時間も費やす必要はありません。そのかわりに、すっきりと構造化されたユーザーフィードバックの傾向を、ダッシュボードで週に1回確認するだけです。 --- ## PMがすぐに取り組める自動化のチャンス PMの業務フローにAI自動化を取り入れたいなら、まずは次の3つの領域から始めましょう。 1. **仕様書からタスクを生成**：プロダクト要求仕様書（PRD）を書き終えたら、要件を解析するカスタムスクリプトに渡し、チーム独自のチケットテンプレートに沿ったJiraのエピックと開発者向けストーリーを下書きさせます。 2. **リリースノートの自動生成**：Gitリポジトリのリリースを、チームのプロジェクト用データベースと連携させます。本番環境にビルドが出るたびに、コミットメッセージとPRのタイトルをもとに、顧客向けのわかりやすいリリースノートの下書きと、社内向けのSlackアナウンスをLLMで生成します。 3. **競合の継続的なモニタリング**：競合のブログやプロダクトローンチのRSSフィードをトリガーに設定します。LLMで各社の週次アップデートを要約し、注力している領域を分類し、自社のプロダクトロードマップに影響しそうな点をハイライトします。 --- ## これからの展望：「AIネイティブ」なプロダクトマネージャー {/* INLINE IMAGE 2 SPECIFICATION Image File Name: "/images/posts/pm-automation/ai-native-pm.webp" Image Prompt: "A conceptual digital workspace showing a PM planning a product strategy while background agents manage execution pipelines, modern editorial graphic, clean purple tones." Alt text: "AIエージェントがバックログの細部を管理し、人間が戦略を担う、AIネイティブなPMのダッシュボードの図" Caption: "これからの役割分担：AIエージェントが実行の細部を担い、PMはビジョンと戦略に集中する" Position: 「私の考えが変わったきっかけ」の直前 */} これから先、プロダクトマネジメントは2つの道に分かれていきます。 従来どおりの手作業による調整に頼るPMは、実行ループの量そのものに押しつぶされてしまうでしょう。AIによってエンジニアリングのコード生成が驚くほど速くなるので、機能をリリースするスピードは上がります。リリースのスピードが上がれば、必要になるフィードバック、データ指標、調整の量は爆発的に増えます。 自分の業務を自動化しないPMは、開発チームにとって最大のボトルネックになってしまうはずです。 一方で、「AIネイティブ」なPMは、継続的な自動化ループを回します。専用のエージェントに、バックログのグルーミング、チケットの下書き、顧客対応のトリアージを任せるのです。実行の細部を自動化されたシステムに委ねることで、顧客への共感、ビジョン、プロダクトのポジショニングに全力を注げるようになります。 --- ## 関連記事 * 不安定なプロンプトスクリプトを、構造化されたステートマシンがどう置き換えるのかは、[プロンプトエンジニアリングの終焉？](/ja/posts/the-end-of-prompt-engineering)をご覧ください。 * データベースやファイルシステムをツールに直接組み込むためのヒントは、[MCPはAIアプリケーションのUSB-Cになる](/ja/posts/mcp-usb-c-of-ai-applications)にまとめています。 * 開発者がターミナル環境でソフトウェアをどうやって速くつくっているのかは、[Claude Code vs Cursor：作り手目線の徹底比較](/ja/posts/claude-code-vs-cursor)をチェックしてみてください。 ## 参考リンク * 開発ツールやAPI連携の標準については、[Microsoft Developer Blog](https://developer.microsoft.com/en-us/)で詳しく紹介されています。 * アジャイルなプロセスやバックログ自動化のパターンについては、[Project Management Institute (PMI) Library](https://www.pmi.org/)で読めます。 * サーバーレスツールを使った自動化ワークフローは、[GitHub Resources](https://resources.github.com/)で確認できます。 --- ## 私の考えが変わったきっかけ 長いあいだ、私は完璧なJiraチケットを書き、ドキュメント用のデータベースの整理に何時間もかける「手を動かす」PMであることを誇りにしていました。自分の価値は、仕様書の細かさと網羅性にあると思っていたのです。 ところが、プレッシャーの大きいローンチの最中に、私は仕事が追いつかなくなりました。次のスプリントに向けた詳細な仕様書を書く時間がなく、エンジニアチームの作業が止まってしまったのです。焦った私は3時間かけて、ロードマップのデータベースを読み取り、PRDのテンプレートをもとにJiraのストーリーを下書きする簡単な自動化スクリプトをつくりました。 下書きされたストーリーを見てみると、何時間もかけて手で書いていたものの90%くらいの出来でした。エンジニアたちは細かな違いなど気にしていませんでした。明確で構造化されたタスクが時間どおりに届いたことを、ただ喜んでくれたのです。 その日、私は気づきました。**PMとしての私の価値は、チケットを書くことにあったのではなく、ゴールに向けて足並みをそろえることにあった**のだと。事務作業を自動化しても、私の関わりが減ったわけではありません。むしろ、顧客や開発者と直接話す時間が生まれたのです。私はチケットの体裁を整えるのをやめて、パイプラインをつくりはじめました。 --- # プロンプトエンジニアリングの終焉？ > モデルがより堅牢になり、開発者がエージェント型のワークフローへ移行するなかで、プロンプトハックの時代は終わりつつあります。未来を握るのはシステムエンジニアリングです。 _Slug: the-end-of-prompt-engineering · 2026-05-15_ {/* SEO METADATA SEO Title: プロンプトエンジニアリングの終焉？　プロンプトハックからシステム設計へ SEO Description: プロンプトエンジニアリングが、テキストのハックから、システムアーキテクチャ、ステートマシン、構造化されたツールループへと移り変わっている理由を探ります。 Keywords: プロンプトエンジニアリング, プロンプトハック, AIシステムエンジニアリング, LLMの設計パターン, エージェント型ワークフロー, AI開発者 Canonical URL: https://www.dailysay.me/ja/posts/the-end-of-prompt-engineering OpenGraph Title: プロンプトエンジニアリングの終焉？　プロンプトハックからシステム設計へ OpenGraph Description: プロンプトエンジニアリングが、テキストのハックから、システムアーキテクチャ、ステートマシン、構造化されたツールループへと移り変わっている理由を探ります。 Twitter Title: プロンプトエンジニアリングの終焉？ Twitter Description: プロンプトハックが廃れ、システムプログラミングがAI開発の主役になりつつある理由。 */} {/* HERO IMAGE SPECIFICATION Image Prompt: "A minimal, modern graphic showing text strings transforming into physical wireframe logic gates, dark workspace background, soft lighting, 16:9 aspect ratio." coverAlt: "ターミナルのテキストプロンプトが、すっきりしたワイヤーフレームのノードで組まれた、高度に構造化された3Dのアーキテクチャ図へと進化していく抽象的なグラフィック" */} 2023年から2024年にかけての「プロンプトエンジニアリング」のゴールドラッシュを覚えていますか？　ネットのグルたちは、LLMに与えるべき正確な魔法の言葉を知っていることこそ21世紀でいちばん価値のあるスキルだ、と主張していました。求人サイトには、モデルにいつ「深呼吸して」「ステップ・バイ・ステップで考えて」「熟練のソフトウェアエンジニアとして振る舞って」と言えばいいかを心得たスペシャリストに向けて、天文学的な年収の求人が並びました。 あれはコンピューティングの歴史のなかでも、奇妙な過渡期でした。私たちはコンピューターチップに自然言語で話しかけ、文字列をハックすることで、隠れた挙動を探り当てようとしていたのです。 しかし2026年半ばの今、景色はまったく違って見えます。独立した専門分野としてのプロンプトハックは、消えつつあります。フロンティアモデルがより賢くなり、指示に素直に従うようになり、エージェント型のアーキテクチャにネイティブに組み込まれるにつれて、焦点が移ったのです。複雑なタスクをこなしてもらうために、長々としたテキストのプロンプトでモデルをなだめすかす必要は、もうありません。そのかわりに、私たちはシステムをつくっています。 「プロンプトを書く人」の時代は終わり、**AIシステムエンジニア**の時代がやってきました。 --- ## 魔法の文字列のもろさ なぜこの変化が起きたのかを理解するには、初期のプロンプトベースのアプリケーションがいかにもろかったかを見る必要があります。3,000文字のプロンプトに頼るソフトウェア機能をつくったことがあるなら、プロンプトエンジニアリングが砂上の楼閣だということに、すぐ気づいたはずです。 * **決定性の欠如**：95%の確率で完璧に動いていたプロンプトでも、モデルの確率的な性質のせいで、96回目の実行でランダムに失敗することがありました。 * **プロバイダーへのロックイン**：Claude 3.5 Sonnet向けに最適化したプロンプトは、GPT-4oやGemini 1.5 Proに送るとしばしば失敗しました。どのモデルにも、自然言語の解釈に独特の細かなクセがあったのです。 * **アップデートによるリグレッション**：プロバイダーがモデルにマイナーアップデートをかけると、モデル内部の重みが変わったせいで、プロンプトが突然壊れてしまいました。 ``` +-----------------------------------+ | Original Prompt: | | "Write JSON output. Be concise." | +-----------------------------------+ | v (Model Version Update) +-----------------------------------+ | Failed Output: | | "Sure, here is your JSON..." | | (Breaks parser with intro text) | +-----------------------------------+ ``` 「魔法の文字列」に頼るのは、安定したソフトウェアをつくるには最悪のやり方でした。インフラのちょっとしたアップデートで、アプリケーションのエンドポイントが返す文字列のフォーマットがランダムに壊れるなんて、ほかのどんなコンピューティング環境でありうるでしょうか？ --- ## 構造化されたシステムへの移行 {/* INLINE IMAGE 1 SPECIFICATION Image File Name: "/images/posts/end-of-prompts/structured-pipelines.webp" Image Prompt: "A clean architectural flowchart diagram showing a structured multi-step LLM system, minimal flat icons, light turquoise and gray colors, editorial style." Alt text: "入力のパース、意図の評価、ツールループの実行、スキーマの検証という構造化されたステップを示すシステムアーキテクチャ" Caption: "モダンなAIシステム設計：モノリシックなプロンプトを、検証つきのモジュール化されたステージに分解する" Position: 「構造化されたシステムへの移行」の直後 */} モノリシックなプロンプトのもろさを解決するために、開発者たちは巨大な指示文を書くのをやめ、タスクを構造化されたパイプラインに分解しはじめました。 モデルに「このユーザーのサポートチケットを読んで、注文を探し、口調を分析して、JSONで返信を書いて」と頼むかわりに、いまはステートマシンを組みます。システムは、それぞれが単一の目的を持つ別々のステップに分割されます。 1. **分類器（Classifier）**：軽量なモデルがチケットのカテゴリを分類します（出力は厳密なenum）。 2. **データ取得（Data Retriever）**：APIクエリで、チケットのメタデータをもとにユーザーの注文情報を取得します。 3. **下書き生成（Draft Producer）**：取得したコンテキストを使って、モデルが下書きを生成します。 4. **検証（Validator）**：最後のコード層で、下書きにハルシネーションが含まれておらず、スキーマのルールに合っていることを保証します。 問題を分解することで、プロンプトそのものの複雑さが下がります。各ノードのプロンプトはもう長いエッセイではなく、シンプルで直接的な指示です。あるステップが失敗しても、グラフのどのノードが原因なのかが正確にわかります。各ステップを独立してテストし、デバッグし、最適化できるのです。 構造化出力を使って、これをどう実装するのかを見てみましょう。モデルにJSONを書かせて正しくフォーマットされることを祈るのではなく、スキーマ検証によって出力の構造を*保証*するのです。 Zodと構造化出力のクライアントを使った、モダンなTypeScriptの例がこちらです。 ```typescript import { z } from "zod"; // 1. モデルの出力に対する厳密なスキーマを定義する const TicketAnalysisSchema = z.object({ category: z.enum(["billing", "technical", "feature_request", "general"]), priority: z.enum(["low", "medium", "high", "critical"]), sentiment: z.enum(["positive", "neutral", "frustrated", "angry"]), suggestedAction: z.string().describe("The next immediate action the team should take"), }); type TicketAnalysis = z.infer; // 構造化されたノードを表す実行関数の例 async function analyzeTicket(ticketBody: string): Promise { // JSON形式で出力するようプロンプトで指示を書くかわりに、 // スキーマをモデルの設定に直接渡す。 const response = await aiClient.chat.completions.create({ model: "gpt-4o-2026-05-10", messages: [ { role: "system", content: "Analyze the customer ticket." }, { role: "user", content: ticketBody } ], response_format: { type: "json_object", schema: TicketAnalysisSchema, // APIレベルで強制される } }); return TicketAnalysisSchema.parse(JSON.parse(response.choices[0].message.content)); } ``` スキーマへの準拠をAPIレベルで強制すれば、プロンプトそのものはごく単純なものになります。「Markdownのタグを含めないこと。『Sure, here is...』で始めないこと。有効なJSONだけを出力すること」と、何段落もかけてモデルに指示する必要はもうありません。モデルの出力トークンは、パーサーのステートマシンに合うよう強制されるのです。 --- ## プロンプトからシステムへ移行するための実践ガイドライン もしまだ長くて複雑なシステムプロンプトを書いているなら、リファクタリングのときです。次のルールを使って、アプリケーションをプロンプトエンジニアリングからシステムエンジニアリングへと移行させましょう。 * **複雑さを分解する**：プロンプトが500語を超えているなら、そのプロンプトはいろいろなことをやりすぎています。複数の連続したLLM呼び出しやツールループに分割しましょう。 * **あらゆる場所でスキーマを検証する**：Zod、Pydantic、ネイティブのJSONスキーマなどのツールを使い、モデルのステージ間でやりとりされる構造化された入出力をすべて検証します。 * **テキストよりコード**：単純な正規表現、データベースクエリ、すっきりしたユーティリティ関数で書けるタスクなら、**LLMを使ってはいけません**。LLMの推論は、意味の解析と統合だけに集中させましょう。 * **プロンプトをバージョン管理する**：システムへの指示はコードと同じように扱います。バージョン管理（git）に保存し、更新のたびに自動のリグレッション評価を走らせ、複数のモデルのエンドポイントでテストしましょう。 --- ## これからの展望：中間表現（IR）としてのプロンプト {/* INLINE IMAGE 2 SPECIFICATION Image File Name: "/images/posts/end-of-prompts/compiler-analogy.webp" Image Prompt: "A high-tech digital compiler diagram showing code compiling into structured prompt tokens, minimal vector artwork, deep purple and neon green colors, dark aesthetic." Alt text: "手書きではなく、コンパイラやフレームワークによって自動生成されるプロンプトの指示を示す図" Caption: "コンパイラのたとえ：プロンプトは人間が書くテキストではなく、コンパイラが出力する中間的なターゲットになる" Position: 「私の考えが変わったきっかけ」の直前 */} エージェントフレームワークが進化するにつれて、人間がプロンプトを書く機会は減っていくでしょう。プロンプトは中間表現（IR：Intermediate Representation）、つまりコンパイラやフレームワークが自動生成する低レベルの命令セットになっていきます。 DSPy（Declarative Self-Improving Language Programs）のようなシステムは、すでにこの考え方が成り立つことを示しています。プロンプトを手で書くかわりに、プログラムの構造（入力、出力、モジュール）を定義し、少数の学習用サンプルを与えます。するとフレームワークがプログラムをコンパイルし、制約付き最適化を使って、使っているモデルに合わせたプロンプトを自動で生成・テスト・最適化してくれるのです。 そんな未来では、プロンプトを手で書くことは、アセンブリ言語を手で書くような感覚になるでしょう。低レベルのデバッグやパフォーマンスチューニングにはまだ役立つものの、ほとんどの開発者は高レベルのロジック、スキーマ、アサーションを書き、指示へのコンパイルはフレームワークに任せるようになります。 --- ## 関連記事 * 標準化されたインターフェースがモジュール型のシステムアーキテクチャをどう支えるのかは、[MCPはAIアプリケーションのUSB-Cになる](/ja/posts/mcp-usb-c-of-ai-applications)をご覧ください。 * AIを活用した開発でテストカバレッジと検証を維持するためのヒントは、[AIでコード品質を保つための原則](/ja/posts/principles-of-maintaining-code-quality-with-ai)にまとめています。 * 開発者体験を変えつつある実践的なツールについては、[Claude Code vs Cursor：作り手目線の徹底比較](/ja/posts/claude-code-vs-cursor)で解説しています。 ## 参考リンク * 構造化スキーマとプロンプト管理については、[OpenAI Developer Blog](https://openai.com/blog)をご覧ください。 * 自己改善型のプロンプトコンパイラや研究論文については、[Stanford NLP Group](https://nlp.stanford.edu/)で読めます。 * 堅牢なエージェントを構築するための開発パターンは、[Vercel AI SDK Docs](https://sdk.vercel.ai/)で確認できます。 --- ## 私の考えが変わったきっかけ 2024年、私は自社プロダクトの分類機能のために、2週間かけてシステムプロンプトを最適化しました。形容詞をいじり、few-shotの例を足し、モデルに「この出力に私の仕事がかかっている」と伝えることまで試しました。精度は92%に達し、自分は天才なんじゃないかと思ったものです。 1か月後、プロバイダーがモデルをアップデートしました。精度は78%まで落ち、モデルが突然ていねいな前置きの文章をつけるようになったせいで、JSONパーサーが構文エラーを吐きはじめました。 そのとき、プロンプトエンジニアリングは幻想だったのだと気づきました。私は堅牢なソフトウェアをつくるかわりに、何週間もかけて、混沌としたブラックボックスのパラメータをいじっていただけだったのです。 私たちはモノリシックなプロンプトを捨て、スキーマの強制と厳密な入力パースを使ったシンプルな3ステップのステートマシンに置き換えました。コードは数十行増えましたが、プロンプトはたった1文に縮みました。精度は98%に上がり、モデルをアップデートしてもそのまま保たれました。私は悟りました。**モデルの不安定さを解決するのは、決してより良いプロンプトではなく、より良いアーキテクチャなのだ**と。 --- # MCPはAIアプリケーションのUSB-Cになる > バラバラだったLLM連携の世界で、Model Context Protocol（MCP）が、モデルとデータソースやツールをつなぐ統一的なオープン標準として台頭しつつあります。 _Slug: mcp-usb-c-of-ai-applications · 2026-05-08_ {/* SEO METADATA SEO Title: MCP：AIアプリケーションとツール連携のためのUSB-C標準 SEO Description: AnthropicのModel Context Protocol（MCP）が、AIモデルとファイルシステム、データベース、エンタープライズAPIをつなぐ業界標準になりつつある理由を探ります。 Keywords: Model Context Protocol, MCP, LLM連携, AIアーキテクチャ, Anthropic MCP, AIツール呼び出し, 開発者体験 Canonical URL: https://www.dailysay.me/ja/posts/mcp-usb-c-of-ai-applications OpenGraph Title: MCP：AIアプリケーションとツール連携のためのUSB-C標準 OpenGraph Description: AnthropicのModel Context Protocol（MCP）が、AIモデルとファイルシステム、データベース、エンタープライズAPIをつなぐ業界標準になりつつある理由を探ります。 Twitter Title: MCP：AIアプリケーションのためのUSB-C標準 Twitter Description: Model Context Protocol（MCP）は、LLMとデータやツールの接続をどう標準化しているのか。 */} {/* HERO IMAGE SPECIFICATION Image Prompt: "A minimal, modern editorial illustration of multiple glowing data conduits merging into a single sleek, metallic interface port, clean background, technical styling, premium product feel, 16:9 aspect ratio." coverAlt: "さまざまなデータノードが、Model Context Protocolを表す中央の光る円形プロトコルアダプタにすっきりと接続されている抽象イラスト。" */} 何年ものあいだ、AIアプリケーション開発の体験は、モバイル機器の黎明期のようなものでした。LLMプロバイダーも、エージェントフレームワークも、開発環境も、それぞれがモデルとデータをつなぐ独自の方式を持っていたのです。ローカルにあるソースコードのディレクトリをClaudeに読み込ませたいなら、スクリプトを書くしかありませんでした。GPT-4oを自分のPostgresデータベースにつなぎたいなら、カスタムのAPIコネクタを自作しました。土台となるフレームワークをLangChainからLlamaIndexに乗り換えれば、データ読み込みのパイプラインを半分書き直すはめになりました。 私たちはカスタムアダプタの海に溺れていました。すべてを束ねる標準のポートがなかったのです。 だからこそ、Model Context Protocol（MCP）は、Function Callingの登場以来、AIエンジニアリングにおける最も重要なアーキテクチャの転換なのです。もともとAnthropicがオープンソースとして公開したMCPは、「AIのUSB-C」としての地位を急速に固めつつあります。LLMがデータソースやファイルシステム、ツールとどうつながるかを抽象化する、シンプルでオープンな双方向の標準です。 $N$種類のモデルと$M$種類の開発環境のあいだで$N \times M$通りの連携を書く代わりに、MCPなら、モデルがクライアントとして標準化されたMCPサーバーと対話する、すっきりとしたプラグアンドプレイのアーキテクチャを実現できます。 --- ## AI開発における連携のボトルネック プロトコルそのものを見る前に、それが解決する問題を詳しく見ておきましょう。LLMアプリケーション開発の初期の波の中で、開発者は大きな壁にぶつかりました。モデルが孤立している、という壁です。LLMは単体では、あなたのコードリポジトリのことも、データベーススキーマのことも、チームのSlackの履歴のことも知りません。 このギャップを埋めるために、私たちはカスタムのパイプラインを作りました。RAG（検索拡張生成）システムを立ち上げ、APIゲートウェイを構築し、独自のツールセットを定義しました。でも、どの連携も一つひとつがオーダーメイドでした。 ``` +--------------+ +-------------+ | AI Model / | ----(Custom)-->| Postgres DB | | Framework | +-------------+ | | +-------------+ | (LangChain/ | ----(Custom)-->| GitHub API | | LlamaIndex) | +-------------+ | | +-------------+ | | ----(Custom)-->| Local Files | +--------------+ +-------------+ ``` このモデル中心の連携パターンは、大きな問題を生みました。まず、すべての接続がその場しのぎのコードで実装されていたため、セキュリティの監査が極めて困難でした。次に、ツールの再利用が制限されました。LangChainのエージェント向けに何日もかけて堅牢なSlackコネクタを作っても、連携部分のラッパーを書き直さない限り、Cursorのような開発ツールやClaude Codeのようなターミナルエディタには簡単に移植できなかったのです。 必要だったのは、関心の分離でした。*データをどう取得するか*と、*モデルがそれについてどう推論するか*のあいだに、境界線が必要だったのです。 --- ## MCPの基本コンセプト Model Context Protocolは、システムを2つの明確なコンポーネントに分けます。 1. **MCPクライアント**：ツールやデータへのアクセスを必要とする開発アプリケーション、IDE、エージェント環境（Cursor、VS Code、Claude Desktopなど）。 2. **MCPサーバー**：特定のデータソースや機能を、標準プロトコルを通じて公開する軽量でモジュール型のプログラム。 ```mermaid graph LR subgraph Clients [MCPクライアント] IDE[VS Code / Cursor] Term[Claude Code CLI] App[カスタムエージェントアプリ] end subgraph Protocol [Model Context Protocol] direction TB JSON[SSEまたはStdpipe上のJSON-RPC 2.0] end subgraph Servers [MCPサーバー] GitSrv[GitHubサーバー] DbSrv[Postgresサーバー] FsSrv[ローカルファイルサーバー] end Clients --> Protocol Protocol --> Servers ``` クライアントとサーバーのあいだの通信は、JSON-RPC 2.0で行われます。ローカルのサーバーには標準入出力（stdio）を、リモートのサービスにはServer-Sent Events（SSE）を使うことで、MCPはアダプタをローカルで動かすことも、クラウドでホストすることも簡単にしてくれます。 プロトコルは、3種類の中核的な機能を定義しています。 * **リソース**（Resources）：読み取り可能なデータソース。ローカルファイル、データベースのテーブル、APIの出力などがこれにあたります。 * **プロンプト**（Prompts）：モデルが構造化された指示を組み立てるのを助ける、標準化されたテンプレート（例：コードレビュー用のプロンプト）。 * **ツール**（Tools）：モデルが外の世界に変更を加えられるようにする、実行可能な関数（例：コマンドの実行やファイルの書き込み）。 --- ## 内部の仕組み：シンプルなMCPサーバーを作る {/* INLINE IMAGE 1 SPECIFICATION Image File Name: "/images/posts/mcp-usb-c/mcp-server-schema.webp" Image Prompt: "A clean, modern software diagram showing the JSON-RPC message flow between an MCP Client and an MCP Server, minimal flat vector style, dark background, blue and teal accents." Alt text: "MCPクライアントとローカルのMCPサーバーのあいだで行われる、リソースの一覧取得と読み込みのリクエストを示すJSON-RPCのシーケンス図。" Caption: "stdio上のJSON-RPCを使った、クライアントとサーバー間の通信プロトコルの流れ。" Position: 「内部の仕組み：シンプルなMCPサーバーを作る」の後 */} これがどれだけシンプルでエレガントかを知るために、Node.jsで基本的なMCPサーバーを実装する方法を見てみましょう。たとえば、ローカルのデータベースのテーブル構造を公開して、エディタで動いているどのAIモデルでも、こちらがコピー＆ペーストしなくてもスキーマを理解できるようにしたいとします。 公式のTypeScript SDKを使った、シンプルなローカルMCPサーバーはこちらです。 ```typescript import { Server } from "@modelcontextprotocol/sdk/server/index.js"; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; import { ListResourcesRequestSchema, ReadResourceRequestSchema, } from "@modelcontextprotocol/sdk/types.js"; // MCPサーバーを初期化 const server = new Server( { name: "schema-inspector", version: "1.0.0", }, { capabilities: { resources: {}, }, } ); // 利用可能なリソースを定義 const SCHEMAS = { "users": "CREATE TABLE users (id SERIAL PRIMARY KEY, email VARCHAR(255), created_at TIMESTAMP);", "posts": "CREATE TABLE posts (id SERIAL PRIMARY KEY, title TEXT, author_id INT REFERENCES users(id));" }; // 1. リソース一覧のハンドラを登録 server.setRequestHandler(ListResourcesRequestSchema, async () => { return { resources: Object.keys(SCHEMAS).map((name) => ({ uri: `db://schema/${name}`, name: `${name} table schema`, mimeType: "text/plain", description: `DDL schema statement for the ${name} table` })), }; }); // 2. リソース読み込みのハンドラを登録 server.setRequestHandler(ReadResourceRequestSchema, async (request) => { const uri = new URL(request.params.uri); const tableName = uri.pathname.split("/").pop(); if (!tableName || !(tableName in SCHEMAS)) { throw new Error(`Resource not found: ${request.params.uri}`); } return { contents: [ { uri: request.params.uri, mimeType: "text/plain", text: SCHEMAS[tableName as keyof typeof SCHEMAS], }, ], }; }); // トランスポートに接続 const transport = new StdioServerTransport(); await server.connect(transport); console.error("Schema Inspector MCP Server running on stdio"); ``` このサーバーをCursorやClaude Desktopのようなエディタで動かすには、クライアントの設定ファイルに起動コマンドの設定を追加するだけです。 ```json { "mcpServers": { "schema-inspector": { "command": "node", "args": ["/path/to/server.js"] } } } ``` 読み込まれると、クライアント（たとえばCursor）は、どんなリソースが利用できるのかをサーバーに自動で問い合わせます。「usersとpostsをJOINするクエリを書くのを手伝って」のようなプロンプトを書くと、Cursorは裏側で`db://schema/users`と`db://schema/posts`のリソースを読み込み、DDLスキーマをプロンプトのコンテキストに直接注入します。 --- ## 実践的な連携戦略 AIエージェントや開発者向けツールを作っているなら、カスタムのAPIクライアントを書くのは今すぐやめるべきです。代わりに、データレイヤーをMCPに合わせましょう。今日から実装を始められる3つの戦略を紹介します。 1. **社内APIを標準化する**：チームの独自AIツールのために社内ダッシュボード用のAPIを作るのではなく、それらのエンドポイントをMCPサーバーでラップしましょう。そうすれば、チームのどのエンジニアでも、自分のIDEの中から直接データベースに問い合わせたり、ビルドを実行したり、ドキュメントにアクセスしたりできます。 2. **コミュニティのサーバーを活用する**：サーバーをゼロから作る前に、増え続けているオープンソースのMCPサーバーの一覧を確認しましょう。GitHub、Slack、Postgres、Jira、Google Maps、ローカルのターミナル向けには、すでに高度に最適化されたサーバーがあります。 3. **ツールの権限を切り離す**：ツールの実行ロジックをMCPサーバーの中に置いておけば、トランスポートのレベルでアクセス制御を管理し、ログを書き出せます。サーバーが明示的に読み書きの権限を与えない限り、エージェントはデータベースにアクセスできません。 --- ## 今後の展望：ユニバーサルなインターフェース {/* INLINE IMAGE 2 SPECIFICATION Image File Name: "/images/posts/mcp-usb-c/mcp-future-architecture.webp" Image Prompt: "A high-tech digital ecosystem diagram showing multiple AI models seamlessly switching between cloud databases, local workspace files, and external APIs via a clean central layer labeled MCP, neon green and purple vector elements, dark premium style." Alt text: "モデルと現実世界のツールのあいだに位置する、ユニバーサルな抽象化レイヤーとしてのMCPを示すアーキテクチャ図。" Caption: "AIアプリケーションアーキテクチャの未来像：統一的なミドルウェア層としてのMCP。" Position: 「考えが変わったきっかけ」の前 */} 近い将来、何をもって「アプリケーション」とするのか、その境界が変わるでしょう。今日の私たちは、グラフィカルユーザーインターフェース（GUI）を通じてソフトウェアを操作しています。明日には、AIエージェントが標準化されたアプリケーションスキーマを使って、リソースやツールを渡り歩くようになります。 あらゆるSaaS企業、クラウドデータベースのプロバイダー、ローカルデバイスのOSがMCP経由で機能を公開するようになれば、連携の複雑さはほぼゼロになります。開発者はもう、API連携を自分で書かなくなるでしょう。データベースの公式MCPサーバーを立ち上げるだけで、コーディングエージェントがテーブルへの書き込み方も、スキーマの読み方も、マイグレーションの実行方法も、すぐに理解してくれるのです。 MCPは、ありふれたAPIフォーマットの一つではありません。自律型ソフトウェアエージェントの時代を動かす、ユニバーサルなミドルウェアなのです。 --- ## 関連記事 * 標準化されたプロトコルの上に構築されたエージェント型コーディング環境がどう違うのかは、[Claude Code vs Cursor：作り手目線の徹底比較](/ja/posts/claude-code-vs-cursor)をどうぞ。 * こうした連携を構築しながら構造の健全性を保つには、[AIでコード品質を保つための原則](/ja/posts/principles-of-maintaining-code-quality-with-ai)をご覧ください。 * AIを使ったワークフローが、単純な自動補完から自律的なターミナル操作へとどう進化しているのか、より広い視点で知りたい方は[コパイロットの先へ：AIエージェントが私の日々のワークフローを変えた理由](/ja/posts/ai-agents-workflow-evolution)を読んでみてください。 ## 参考リンク * オープンソース化の発表については、[Anthropic MCP Blog](https://www.anthropic.com/news/model-context-protocol)で詳しく読めます。 * プロトコルの公式仕様とドキュメントは、[Model Context Protocol公式サイト](https://modelcontextprotocol.io/)で確認できます。 * 標準化されたアーキテクチャを採用した開発者ツールについては、[Vercel Developer Blog](https://vercel.com/blog)が参考になります。 --- ## 考えが変わったきっかけ 長いあいだ、私はLLM連携の未来はもっと賢いモデルにあると信じていました。コンテキストウィンドウが数百万トークンにまで広がれば、ドキュメントも、データベースのダンプも、リポジトリのコードも、すべてそのままモデルのプロンプトに放り込めばいい。そう思っていたのです。 でも、本番環境で動くエージェントを作ってみて学んだのは、ボトルネックはコンテキストのサイズではなく、**ノイズとアクセス制御**だということでした。生のログやテーブルをプロンプトに流し込むと、推論の効率は落ち、トークンのコストは上がり、セキュリティ上の脆弱性も生まれます。 MCPによって、LLMはデータベースではなくCPUなのだと思い知らされました。従来のマイクロプロセッサと同じように、LLMにもきれいなメモリキャッシュと厳格なデバイスドライバが必要です。MCPは、そのドライバを提供してくれます。ローカルのMCPサーバー経由でエディタをPostgresデータベースにつなぎ、モデルが遅延なく、スキーマについて明快に推論していくのを見た瞬間、もう後戻りできない地点を越えたのだと悟りました。私たちはついに、自分たちのUSB-Cを手に入れたのです。 --- # 人生を記録する、私なりの方法 > 仕事やプロジェクト、旅や食べもの、そのときどきの考えまで記録しています。このブログは、これまでの経験と試行錯誤を整理して、次の選択を少しでもよくするための個人的な作業ノートです。 _Slug: built-slowly-updated-daily · Sat Feb 07_ 人生を記録する、私なりの方法 私はプロジェクトマネージャーとして働いています。 スケジュールを整理し、問題を見つけ、いろいろな人の意見を調整しながら、ひとつの成果をつくりあげていく仕事です。そのせいか、日常でも同じような考え方をすることがよくあります。 やりたいことを整理したら、まずは実行してみます。結果が期待と違えばその理由を振り返り、次は何を変えるかを考えます。計画どおりに進まない日も多いですが、その過程で少しずつ、自分なりの基準をつくっているところです。 このブログは、そうした経験を記録するために始めました。 仕事を通して学んだこと、プロジェクトを進めるなかで経験した試行錯誤、新しいサービスをつくりながら悩んだことを書き残します。旅先で見つけた場所や印象に残った料理、その日ふと浮かんだ考えのような、もう少し個人的な話も一緒に記録します。 それぞれのテーマはばらばらに見えるかもしれませんが、結局はどれも、私が自分で経験したことです。 きれいにまとまった成功例だけを残したいわけではありません。計画が狂った理由、思ったより難しかったところ、そのときは最善だと思ったのに、あとから振り返ると悔いが残った選択も、正直に記録するつもりです。 記録を残しておけば、経験はただの過ぎたことで終わりません。 どんな状況でどんな決断をしたのかを振り返ることができ、似たような問題にぶつかったときに、少しでもよい判断をする助けになります。時間がたって考えが変わったなら、その変化もまた、ひとつの記録になります。 長期的には、自分でつくった会社を経営し、その会社を100万ドル以上の価値を持つ事業に成長させることを目標にしています。 まだ始まったばかりで、具体化しなければならない部分もたくさんあります。だからこそ、完成した結果だけを見せるのではなく、目標に向かう過程そのものを残していこうと思います。何を試し、どんな問題があり、そのあと何を変えたのかを、こつこつ記録していくつもりです。 このブログは、華々しい成功談を見せるための場所ではありません。 仕事と人生で経験したことを忘れないための、個人的な作業ノートに近いものです。時間がたってから読み返したとき、当時の悩みや選択が理解できる記録であれば、それで十分です。 完璧に準備してから始めるのではなく、いまからひとつずつ記録していこうと思います。 --- # メキシコ旅行記 02 — バンクーバーでひと休みして、ついにメキシコシティへ > バンクーバー国際空港での乗り継ぎ、メープルリーフ・ラウンジ、エア・カナダのビジネスクラスを経て、メキシコシティに着くまで。長い旅の初日を締めくくった記録。 _Slug: mexico-travel-diary-02-vancouver-to-mexico-city · 2025-10-01_
バンクーバー国際空港にあるエア・カナダのメープルリーフ・ラウンジの入口
メキシコへ向かう前に、バンクーバーでしばし立ち止まった時間。
## 乗り継ぎ地でのひと休み バンクーバー国際空港に降り立って機外に出ると、ひんやりとしたカナダの空気が、長距離フライトで重くなった体を目覚めさせてくれた。でも、旅はまだ終わっていない。メキシコシティ行きの次の便まで、数時間の待ち時間が残っていた。 乗り継ぎは、目的地へ行くためにただ通り過ぎる空白の時間ではない。ひとつの国から別の国へと、心がゆっくり移っていく猶予の時間だ。長かった最初のフライトの疲れをほぐし、これから降り立つメキシコという見知らぬ土地を迎えるために、体と心のチューニングをし直すときだった。 --- ## バンクーバー乗り継ぎ情報 ``` [仁川国際空港 (ICN)] ──> [バンクーバー国際空港 (YVR)] ── (現在地) ──> [メキシコシティ国際空港 (MEX)] ``` ### 📍 乗り継ぎ地の位置情報 * **場所**：バンクーバー国際空港（Vancouver International Airport、YVR） * **役割**：乗り継ぎ空港（Transit Airport） * **座標**：`49.193333, -123.175659` * **地図**：[バンクーバー国際空港の地図を見る](https://www.google.com/maps/search/?api=1&query=49.193333%2C-123.175659) --- ## メープルリーフ・ラウンジでひと休み 長時間、狭い機内にいたせいで、体はかなりくたびれていた。乗り継ぎの待ち時間に、エア・カナダのメープルリーフ・ラウンジへ向かった。空港のせわしない喧騒から離れて、落ち着いて休める場所が必要だった。
メープルリーフ・ラウンジに用意された新鮮なサラダと赤い飲み物
待ち時間にラウンジでつまんだ軽食。長いフライトの直後なので、胃にやさしいサラダを選んだ。
ラウンジの一角に席を取り、軽くつまめるものを取ってきた。新鮮なサラダと冷たい赤い飲み物で、乾いていた口のなかを潤す。おいしいものをたっぷり楽しむためというより、疲れた体を整えるための軽い食事だった。ラウンジの外の、空港のめまぐるしい流れとは対照的なこの落ち着いた空間で、静かに息を整えることができた。
比較的すいていて快適にしつらえられた、メープルリーフ・ラウンジ内の座席スペース
ゆったりとしたラウンジの様子。ソファに座って荷物を下ろし、気持ちを落ち着けた。
飛行機に乗っているだけで体に力が入りっぱなしだったのか、ふかふかのソファにもたれて座ると、緊張がほどけていった。カナダという国の土を直接踏むことはできず、空港の片隅のラウンジにいるだけなのに、日常から完全に切り離されたこの非日常の感覚が、旅の気分を少しずつふくらませてくれた。 --- ## メキシコシティへの最後のフライト いつの間にか乗り継ぎの時間が過ぎ、メキシコシティ行きの便に搭乗する時間になった。今回の旅の、最後の長距離区間だ。
エア・カナダのビジネスクラスの窓側席。テーブルに置かれた飲み物、ナッツ、タブレットと、窓の外の景色
最後のフライトの座席。ウェルカムドリンクとナッツをお供に、窓の外を眺めた。
ありがたいことに、今回のフライトはビジネスクラスの窓側席で、自分だけのスペースがたっぷりあった。席について上着を片づけ、テーブルにタブレットとウェルカムドリンク、ナッツを並べる。ようやく体をゆったり横たえられるという安堵が押し寄せてきた。この飛行機が次に車輪を下ろす場所が、あれほど思い描いていたメキシコなのだという事実が、心のなかにゆっくりと染みこんでいった。 --- ## 雲の上のディナー 機体が安定して巡航に入ると、お決まりのように食事が出てきた。今回は、この便が南へ、メキシコへと向かっていることを知らせるかのように、テーブルクロスがきれいに敷かれた食事が用意された。
白い皿に盛られたチキンのグリル、ごはん、温野菜とサラダ、パン、デザートの機内食セット
メキシコへ向かう機内で出された夕食。チキンと温野菜、ごはんがバランスよく組み合わされていた。
メインのチキン料理と温かいごはん、新鮮な野菜サラダとパン、そして甘いデザートを、ゆっくりと平らげていった。空港を離れ、上空で食べる二度目の夕食は、前よりも少し落ち着いていて、心地よかった。 --- ## カナダの空を越えて 空の道は目に見えない地図のようなもので、窓の外を眺めても、いまどのあたりを飛んでいるのか見当がつかないことが多い。
機内の窓から見下ろす、果てしない空と流れる雲
飛行機の窓越しに眺めた、果てしない雲と空。
窓の向こうに、雲の海がどこまでも続いていた。 海と国境を越えていくあいだ、目の前に広がる青と雲だけが、変わらない道しるべになってくれた。 地平線に沿って流れていく雲を眺めながら、物思いにふけった。バンクーバーからメキシコシティへ向かう航路は、大陸の背骨をなぞるように、ゆっくりと南へ長く延びていた。 --- ## 疲れとの向き合い方 仁川を出発してからかなりの時間がたっていたので、いくら座席が快適でも、頭が重くなり、目が疲れてくるのは避けられなかった。そこで、機内で出している疲労ケア向けのドリンクを選んだ。
エア・カナダの機内で飲んだ、ビタミン入りの健康志向の缶飲料
長引くフライトでたまった疲れをいやすために選んだ、手軽な健康補給用のビタミンドリンク。
薬のように疲れをすぐに消してくれる、劇的な変化を期待したわけではない。ただ、体の緊張をほぐし、乾いたのどをうるおすための、軽くてさわやかな選択だった。冷たい飲み物がのどを通っていくと、ぼんやりしていた頭が少しすっきりしたような気がした。 --- ## 機内で出会った、好奇心をそそるクラマト ドリンクメニューを眺めていると、興味をそそるカナダの伝統的な飲み物を見つけた。「クラマト（Clamato）」という、ちょっと変わった名前の飲み物だ。
プラスチックのカップに入った赤いクラマトと氷
カナダの飲み物文化が詰まったクラマト。トマトジュースと貝のだしが混ざった、独特の風味がある。
クラマトは、トマトベースの味に貝のエキス（Clam Broth）とさまざまなスパイスを加えてつくった、カナダの個性的な飲み物だ。カナダでは、これをベースにウォッカなどを混ぜた、二日酔い覚ましやブランチ向けのカクテル「シーザー（Caesar）」がよく飲まれているという。機内で味わったクラマトは、なじみのない塩気のある貝のうま味とトマトの酸味が混ざり合って、なんとも不思議な印象を残した。科学的に二日酔いが治るわけではないだろうけれど、現地の文化を一風変わった味で体験できる、楽しいひと口だった。 --- ## 移動のひとコマ
旅の途中でカメラに収めた、静かな道中の記録
カナダからメキシコへ移動する途中で残したワンシーン。
--- ## メキシコシティに到着 ついに飛行機が高度を下げ、メキシコシティ国際空港に着陸した。ドアが開いて外へ歩き出したとき、ふわっと押し寄せる知らない匂いと、スペイン語であふれる案内表示に、ようやくメキシコに着いたのだと実感した。 ### 📍 到着地の位置情報 * **場所**：メキシコシティ国際空港（Aeropuerto Internacional Benito Juárez / MEX） * **役割**：到着空港（Arrival Airport） * **座標**：`19.4363003, -99.0720978` * **地図**：[メキシコシティ国際空港の地図を見る](https://www.google.com/maps/search/?api=1&query=19.4363003%2C-99.0720978) 長距離移動の締めくくりに、パスポートを用意した。入国審査を無事に終え、空港の重たい空気をかき分けるようにして、タクシー乗り場へ歩いていった。 --- ## タクシーの窓から見た、最初の街のかけら 空港で私たちを乗せた公式タクシーは、メキシコシティの市街地をせわしなく走りはじめた。窓の外に次々と現れる風景は、私の知っているアジアや北米の雰囲気とはまったく違う層を持っていた。
タクシーの助手席の窓越しに見える、メキシコシティ市街地の記念碑的な彫刻
空港から宿へ向かう途中で出会った、メキシコシティの街の風景。
タクシーの窓の外を、そびえ立つ銅像や遺跡が通り過ぎていった。Cuauhtémoc（クアウテモック）は、テノチティトランの最後のアステカの統治者として知られている。空港から宿へ向かう道で彼の名前と姿に出会い、メキシコシティが持つ歴史の層を初めて実感した。流れていく車窓の外に見えたメキシコシティの最初の顔は、とても見慣れなくて、そして力強かった。 --- ## ようやく荷物を下ろす 長い時間をかけて、ようやく今夜泊まる宿、Pandora Hotelにたどり着いた。
居心地よくモダンにしつらえられた、パンドラホテルのロビー、あるいは室内
ついにたどり着いたパンドラホテルの館内。長かった移動にようやく区切りがついて、ほっとした。
重いスーツケースを引きずって部屋に入り、床に置いた。ベッドにどさっと腰を下ろして、ゆっくりあたりを見回すこの瞬間こそ、長い旅のなかでいちばん待ち望んでいた区切りだったのかもしれない。今日一日でたまった疲れを洗い流すために、荷物を整理した。 ### 🏠 宿の詳細情報（Pandora Hotel） * **住所**：Nápoles 35, Juárez, 06600 Ciudad de México, CDMX, Mexico * **別名**：Pandora House、Pandora Luxury Suites Reforma by VH * **確認用リンク**： * [Googleマップで場所を見る](https://www.google.com/maps/search/?api=1&query=Pandora+Hotel%2C+N%C3%A1poles+35%2C+Ju%C3%A1rez%2C+06600+Ciudad+de+M%C3%A9xico%2C+CDMX%2C+Mexico) * [Agodaで宿を見る](https://www.agoda.com/pandora-luxury-suites-reforma-by-vh/hotel/mexico-city-mx.html) > 💡 宿の情報や料金は時期によって変わることがあるので、予約ページで最新の内容を確認しておこう。 --- ## なじみの味との思わぬ再会 部屋でざっと荷物を片づけ、必要な日用品を買いにホテルの外へ出た。遠くまで行く体力はなかったので、ホテルのすぐ隣の店に入ったところで、思いがけない光景に笑いがこみ上げた。
ハングルの案内板と韓国のカップラーメン、韓国のお菓子が並ぶ、韓国のコンビニのような雰囲気の店の外観
宿のすぐ隣にある、韓国食品の専門店。
一日じゅう韓国から遠ざかっていると思っていたのに、宿のすぐ隣でまた韓国の食べ物に出会った。棚いっぱいに並ぶ韓国語のパッケージやラーメンの箱を見ていると、ふと不思議な親近感がわいてきた。見知らぬメキシコシティのど真ん中で初日に出会った韓国の味は、長い移動でたまった疲れのなかに、小さな安心と笑いを運んでくれた。 --- ## 初日を終えて 仁川からカナダへ、そしてメキシコへと続く24時間を超える移動の末に、ようやく居心地のいい自分の部屋で荷をほどいた。 ついに目的地にたどり着いたという実感は、壮大な景色を前にした瞬間よりも、重いリュックを床にどさっと下ろして、ゆっくりとまわりを見回す、まさにこのささやかな瞬間に、より鮮やかに、そして静かに訪れる。 明日から始まる本当のメキシコの時間を待ちわびながら、長かった一日のかけらを、心地よい安堵でそっと包みこむ。 --- * [前の話：メキシコ旅行記 01 — 仁川からバンクーバーへ、長い旅のはじまり](/ja/posts/mexico-travel-diary-01-incheon-to-vancouver) * 次の旅行記は近日公開予定。 --- # メキシコ旅行記 01 — 仁川からバンクーバーへ、長い旅のはじまり > 2025年10月1日、メキシコへの長い旅が仁川国際空港から始まった。エア・カナダに乗って太平洋を渡り、バンクーバーに着くまでの最初の記録。 _Slug: mexico-travel-diary-01-incheon-to-vancouver · 2025-10-01_ **個人情報の保護について**：本文で使っている搭乗券とパスポートの画像（IMG_6600）は、個人情報の流出を防ぐため、マスキングと匿名化の処理を済ませた差し替え画像で、安全に表示している。
仁川国際空港で出発を待ちながら手にしたパスポートとエア・カナダの搭乗券
2025年10月1日、パスポートと搭乗券を手に、メキシコへの旅が始まった。
## 旅のはじまり、そして実感 ずっと前から計画していた旅なのに、毎日同じことのくり返しだった日常の名残は、空港鉄道に乗り込む瞬間になっても、なかなか消えなかった。仁川国際空港に着いて出国手続きを済ませ、搭乗ゲートの前でパスポートと搭乗券を握りしめたとき、ようやく実感がわいてきた。慣れ親しんだソウルの日常を抜け出して、見知らぬ時間と言葉のなかへ入っていく瞬間だった。 目的地のメキシコシティは、まだはるか遠くにあった。太平洋を渡ってカナダのバンクーバーで一度乗り継ぎ、そこからさらに南へ飛んで、ようやくたどり着ける距離だ。飛行機に二度乗る長い旅を前に、胸の高鳴りと同時に、この先待っている長距離フライトの疲れが、静かに押し寄せてきた。けれど旅は、目的地に着いたときではなく、慣れた日常を離れるこの瞬間から始まるものだ。 --- ## 旅のルート（Route Overview） 今回の旅は、韓国を出発し、カナダを経由してメキシコへと続く長い空の道だ。第一章では、仁川を出発して、最初の経由地であるバンクーバー国際空港に着くまでをたどる。 ``` [仁川国際空港 (ICN)] ── (フライト1) ──> [バンクーバー国際空港 (YVR)] ── (フライト2) ──> [メキシコシティ国際空港 (MEX)] *この記事の範囲* ``` ### 📍 旅の位置情報 | 項目 | 仁川国際空港（ICN） | バンクーバー国際空港（YVR） | | --- | --- | --- | | **役割** | 出発地（Departure Airport） | 乗り継ぎ地（Transit Airport） | | **座標** | 37.463333, 126.440002 | 49.193333, -123.175659 | | **地図** | [仁川国際空港の地図を見る](https://www.google.com/maps/search/?api=1&query=37.463333%2C126.440002) | [バンクーバー国際空港の地図を見る](https://www.google.com/maps/search/?api=1&query=49.193333%2C-123.175659) | --- ## 韓国を離れて 搭乗開始のアナウンスが流れ、人の列についてエア・カナダの機内に入った。狭い通路を抜けて座席を見つけ、荷物を片づけて腰を下ろす。窓の外で、なじみの仁川空港の駐機場と管制塔が遠ざかっていくのを眺めながら、深く息を吸い込んだ。ここから何時間かは、地上ではなく空の上で過ごすことになる。エンジンの重い振動が足の裏から伝わってきて、機体がゆっくりと動きはじめた。 --- ## 太平洋上空での最初の食事 離陸して機体が安定飛行に入ると、客室乗務員たちがせわしなく動きはじめた。長距離フライトでの機内食の時間は、ただ空腹を満たす以上の意味を持つ。狭い座席に閉じ込められ、退屈に過ぎていく飛行時間のなかで、唯一感覚をリフレッシュできる貴重な休憩なのだ。
肉料理とマッシュポテト、野菜、パン、水、そして個包装の白菜キムチがのったエア・カナダの機内食のトレー
エア・カナダで出された最初の機内食。温かいメイン料理と一緒に、パック入りのキムチがついてきた。
最初の機内食のトレーには、温かい牛肉料理とマッシュポテト、温野菜、ロールパン、そして水がのっていた。隅に添えられた小さなパック入りのキムチが目にとまる。機内でなじみのある韓国の味に出会うと、思いがけずほっとさせられる。温かい料理をゆっくり噛みしめながら、この先まだ続く長いフライトに必要なエネルギーを補給した。 --- ## 小さなカナダのひとかけら 機内食を終え、照明が落とされた客室で眠ろうとしたけれど、なかなか寝つけなかった。乾いて重たい空気が漂う客室で、乗務員に飲み物としてカナダのビールを頼んだ。
エア・カナダの機内で出されたモルソン・カナディアンの缶ビールとプラスチックのカップ
機内で味わったモルソン・カナディアン。カナダに着く前に、まずは飲み物を通してその国に触れることになる。
出てきた缶は、カナダを代表するビールブランドのひとつ、「モルソン・カナディアン（Molson Canadian）」だった。冷えたビールをカップに注いでひと口飲みながら、まだ足を踏み入れていないカナダという場所の空気を、この一缶でひと足先に想像してみた。夜空を横切っていく機内の静けさのなかで、炭酸の爽快感が少しずつ緊張をほぐしてくれた。 --- ## 機内で迎える朝 何時間か浅い眠りと目覚めをくり返しているうちに、いつの間にか窓の外が少しずつ明るくなってきた。乗務員たちがふたたび照明をつけ、朝食の準備を始めた。機内の時間は現実の時間帯とずれていて、腹時計よりも客室の照明の明るさで朝と夜が決まることが多い。
スクランブルエッグ、ベーコン、ベビーポテト、きのこ料理に、フルーツカップとパンがついた朝の機内食
バンクーバー到着前に出された二度目の機内食。卵料理とベーコン、ベビーポテトがメインだった。
朝のメニューは、スクランブルエッグとベーコン、ローストしたベビーポテト、きのこ料理。添えられていたのは、甘いフルーツカップとロールパン、そしてミネラルウォーターだ。こわばっていた体を軽く動かしながら、温かい朝食を食べ終えた。朝ごはんを済ませると、最初の経由地であるバンクーバーにいよいよ近づいてきたことが、実感として迫ってきた。 --- ## バンクーバーに着く前に 朝食のトレーが片づけられてまもなく、バンクーバー国際空港への着陸準備に入るという機内アナウンスが流れた。長かった最初の空の旅が、いよいよ終わりに差しかかっていた。 窓の外に、カナダ西海岸の景色が少しずつ見えてきた。長いフライトの末に、ようやく雲の下に広がる大地が見えたとき、疲れのなかにも、目的地に一歩近づいたという安堵がこみ上げてきた。 --- ## 最初の区間を終えて バンクーバーは、この旅の最終目的地ではない。メキシコシティへ向かうために数時間とどまるだけの、一時的な経由地にすぎない。それでも、韓国を離れ、太平洋を渡ってカナダの地に降り立った瞬間、頭のなかでぼんやりと思い描いていただけのメキシコ旅行が、ようやく確かな現実として迫ってきた。慣れ親しんだ時間帯といつもの言葉から完全に抜け出したいま、私の旅はもう、深いところで始まっていた。 --- [次の話：メキシコ旅行記 02 — バンクーバーでひと休みして、ついにメキシコシティへ](/ja/posts/mexico-travel-diary-02-vancouver-to-mexico-city)