1. はじめに
2. ポイント1:設計書を書いてもらいましょう
3. ポイント2:Geminiを使うときの指示の出し方
4. ポイント3:自分で修正したら「読み直して」と必ず伝える
5. まとめ

はじめに

生成AIを使ってコード生成や修正を行うことは、もはや特別なことではなくなってきました。 Gemini や CodeX、Copilot、Cursor など、選択肢も増え、「うまく使えばかなり楽になる」という実感を持っている方も多いと思います。

• 途中から意図と違う方向に進み始める
• さっきまでの前提を忘れたような修正をしてくる
• replace に失敗して延々とやり直しを始める

この記事では、生成AIでコードを書くときに安定して進めるためのちょっとしたポイントを紹介します。 特に、コード生成や修正を生成AIに任せる機会が多い方に向けた内容です。

ポイント1：設計書を書いてもらいましょう

機能追加、不具合修正やリファクタリングを生成AIに依頼するとき、いきなり「ここを直して」と指示していないでしょうか。 実はこのやり方だと、生成AIが目の前の修正作業だけに集中してしまい、全体の前提を忘れることがよくあります。 おすすめなのは、最初に「どういう修正をしたいのか」を設計書（Markdown）として書いてもらうことです。

初回の出力は、設計書を書かなくても比較的安定して良い結果が出ることが多いです。 しかし、修正や追加依頼を繰り返していくうちに、最初の前提を少しずつ忘れ、 意図と違う方向へ進み始めることがあります。

設計書を用意しておくことで、 「今回はこの前提で直していたよね」と立ち返ることができ、 迷走を防ぐだけでなく、迷走後のリカバリーにも役立ちます。

例えば、

• どんな不具合を直したいのか
• どの方針で修正したいのか
• 影響範囲はどこか

といった内容をまとめたドキュメントを作り、その上で 「調査結果や修正方針をこの設計書に追記してください」 と指示します。

こうしておくと、修正や追加依頼を重ねたときに、 最初の前提が少しずつ崩れていくことを防ぎやすくなります。 生成AIが迷走し始めたときも、設計書という"基準点"に戻すことができます。 また、途中でセッションを切った後でも、「この設計書通りに進めたけど、ここに不具合があるんだよね」 と前提を思い出させることができます。 前の情報のうち「大事なことだけ」を引き継ぐ手段として、設計書はとても有効です。

ただし、生成AIも人間と同じで、情報を大量に与えられると注意が分散する傾向があります。

そのため、毎回すべての設計書を読ませるのではなく、 今回の修正と関連する方針だけを再掲するほうが、 生成AIの注意が分散せず、出力が安定しやすいです。

ポイント2：Gemini を使うときの指示の出し方

これは Gemini を使っている場合の話ですが、git の履歴や差分を調査させるときに、 そのまま git log や git diff を実行させると、なぜか数分待たされることがあります。

そこでおすすめなのが、 「調査結果を一度ファイルに保存して、そのファイルを見て判断してください」 と指示することです。

例えば、git log や git diff の結果を一時ファイルに出力させてから、それを読み取らせるようにすると、驚くほどスムーズに進むことがあります。 理由は正直よく分かりませんが、少なくとも体感としては そのままコマンドを実行させるより安定します。

Gemini 特有の挙動かもしれませんが、一度試してみる価値があります。

ポイント3：自分で修正したら「読み直して」と必ず伝える

これもGeminiを使う場合に多い話なのですが、LLM全般に少なからずあるポイントと思われます。 生成AIに修正を任せている途中で、自分でソースコードやMarkdownを少し直したくなることはよくあります。

• 改行を整えたい
• 「てにをは」を直したい
• 変数名を変えたい
• 行の順番を入れ替えたい

こうした修正を 自分で行った後に、そのまま続きを依頼すると、生成AIが大混乱することがあります。replace コマンドが失敗し、「もう一回やります」を繰り返し、気づいたら10分過ぎてしまった⋯ということもよくあります。

これを防ぐためには、

「こちらで修正したので、最新の内容を読み直してください」

と、明示的に伝えることで改善されることがよくあります。 それでもうまくいかない場合は、無理に続けず セッションを切って新しく始める方が早いこともあります。

おそらく、モデル内部に前回の状態を強く保持していて、差分がうまく当たらず混乱しているのだろう、というのが推測です。 理由を説明すると気をつけてくれることもありますが、体感では半分くらいは無視されてしまいます。 そういうときは、割り切って新しいセッションで続きの作業を進めることがおすすめです。

また、せっかく「てにをは」やトンマナを修正したのに、 追加のドキュメント修正を依頼したら元に戻されることや、 こちらで変数名を変えたのに別の箇所の再修正を依頼したら、変数名まで元に戻された⋯ こうした現象もよく起こります。

その場合は、無理に続けるよりも、 一度セッションを切り替えるほうが結果的に早いことも多いです。

そしてそのときに役立つのが、ポイント1で紹介した設計書です。 設計書があれば、前提を明示的に再共有できるため、 新しいセッションでも迷走しにくくなります。

まとめ

CopilotやCursorでは、ここまで気を遣わなくてもよい、という話もあるようですが、 今回紹介したやり方でかなり安定して生成AIを使えるようになりました。 また、今回コード生成にフォーカスしていますが、コード生成以外の場合でも今回の3つのポイントは有効だと考えています。

生成AIは賢いですが、前提をどう渡すか、どう指示を出すか、どこで区切るかによって、結果は大きく変わります。 もし最近「生成AIが言うことを聞いてくれないな......」と感じている方がいれば、ぜひ一度お試しください。

目次

1. はじめに
2. プロジェクトの概要 ― 障害対応を生成AIで効率化する
3. 全体の構想 - PowerAutomate × Copilot Studioによる自動化
4. 実際に構築したフロー - Microsoft 365 Copilotでできること
5. 振り返りと教訓
6. おわりに

1. はじめに

2026年現在、生成AIサービスは目的や専門性に合わせて非常に多くの選択肢がありますが、その中でも、Microsoft Copilotは比較的、大企業に選ばれている印象があります。

本記事では、筆者が生成AIを活用したPoCの開発支援に携わった経験をもとに、Microsoft Copilotを利用した業務改善の一例を紹介します。当該プロジェクトにおいては、技術全般のサポートという役割で参画しました。全体の開発方針を考えたり、メンバーが開発で詰まりそうな箇所を先回りして技術調査したりといった裏方の立場です。直接開発を行ったのは先方のメンバーであり、非エンジニアのチームが主体となってPoCを推進したプロジェクトでした。

このプロジェクトでは、まずCopilot単体で実現できる機能を追求し、十分に実用的な仕組みを構築することができました。本記事の内容が、少しでもご参考になれば幸いです。

2. プロジェクトの概要 ― 障害対応を生成AIで効率化する

今回のPoCで対象としたのは、システム障害発生時の初動対応です。

多くの企業では、システムに障害が発生すると監視ツールなどから障害通知メールが届きます。担当者はそのメールの内容を確認し、障害の概要を把握したうえで、過去の事例やドキュメントを参照しながら発生原因を推測し、対応策を検討します。この一連の作業は、経験豊富な担当者であればスムーズに進められますが、経験の浅いメンバーにとっては時間がかかり、対応の遅れにつながることもあります。

そこで本PoCでは、障害通知メールの内容を生成AIに読み込ませ、以下の情報を自動的に生成させることを目指しました。

• 障害の概要(何が起きているかの要約)
• 想定される発生原因
• 推奨される対応策

これにより、経験の浅い担当者でも迅速に初動対応の方針を立てられるようになり、チーム全体の障害対応スピードの向上が期待できます。

3. 全体の構想 - PowerAutomate × Copilot Studioによる自動化

当初描いていた理想のフローは、障害通知メールの受信から対応策の共有までを、人手を介さずワンストップで完結させるものでした。具体的には、以下のような構成を想定していました。

【当初構想のフロー】

障害通知メール受信
↓
PowerAutomate(トリガー：メール受信)
↓ メール本文・件名などを抽出
Copilot Studio(生成AI処理)
↓ 障害概要・原因・対応策を生成
Teams(結果を通知)

まず、障害通知メールの受信をPowerAutomateのトリガーとして設定します。PowerAutomateがメールの本文や件名といった情報を抽出し、Copilot Studioへ連携します。Copilot Studioでは、あらかじめ設定したエージェント設定に基づいて、障害の概要や発生原因、対応策などを生成します。最後に、その生成結果をTeamsのチャネルへ自動投稿し、関係者全員がすぐに確認できる状態にします。

この構成が実現できれば、障害通知メールを受信してから対応策がチームに共有されるまでの流れがすべて自動化され、担当者は生成された対応策を確認して実際の対応に集中するだけで済みます。PowerAutomateとCopilot Studioの組み合わせは、Microsoft 365のエコシステム内で完結するため、追加のインフラ構築も不要であり、非エンジニアにとっても取り組みやすいアプローチとなっています。

4. 実際に構築したフロー - Microsoft 365 Copilotでできること

まずはCopilot Chatを使用して目的の情報取得を実現するために、以下のようなフローを構築しました。メールの取り込みは手動で行いますが、生成AIによる障害分析という核心部分はしっかりと実現できています。

【実際のフロー】

障害通知メール受信
↓ (手動)担当者がメール内容をコピー
Copilot Chat(生成AI処理)
↓ 障害概要・原因・対応策を生成
担当者が結果をもとに対応を実施

ステップ1：SharePointへのドキュメント格納とナレッジ登録

まず、事前準備として、障害対応に必要な資料やドキュメントをSharePointに格納します。たとえば、過去の障害対応履歴やサーバー管理台帳などが該当します。

次に、Copilot Chatのナレッジ設定で、これらのSharePoint上のドキュメントを参照先として登録します。これにより、Copilotは汎用的な知識だけでなく、自社固有の情報も踏まえた回答を生成できるようになります。

ステップ2：障害通知メールの内容をCopilot Chatへ入力

障害通知メールを受信したら、担当者はメールの本文をコピーし、Copilot Chatに貼り付けます。あらかじめ設定したエージェント設定をもとに、回答が生成されます。

ステップ3：生成結果をもとに対応を実施

従来であれば過去の資料を一つ一つ探し、経験と勘に頼って対応策を考えていたプロセスが、Copilot Chatへの入力ひとつで大幅に効率化されたことは、大きな前進です。

5. 振り返りと教訓

プロジェクト全体を振り返り、特に重要だと感じた教訓を共有します。

情報システム部門の協力は必須

ライセンスの管理や社内のITポリシーに関する判断は、情報システム部門の管轄であることが一般的です。 今回、業務部門のメンバー中心のプロジェクトで、先方の情報システム部門の担当者がプロジェクトに参加していなかったため、ライセンスやアクセス制約の確認が遅くなりました。

今後、同様の開発支援型プロジェクトに携わる際には、プロジェクトの初期段階で先方の情報システム部門の担当者をメンバーに加えていただくことを強く推奨するつもりです。

「完璧」でなくても価値は出せる生成AIサービスの強み

今回のPoCでは、一部分の実現のみとなってしまいました。しかし、手動のステップが入ったとしても、生成AIを活用した障害分析そのものは十分に機能し、従来の対応プロセスと比較して明確な効率化が達成できました。試験的に本PoCを実運用で取り入れたところ、一次切り分けにかかる時間は約80%削減し、目に見えるほど対応品質の安定性も向上したようです。

本件の事例がすべてのプロジェクトで当てはまるというわけではないですが、単体でも十分に既存業務の効率化を果たし得る生成AIサービスに対して改めてポテンシャルの高さを感じました。いまひとつ生成AIサービスの利用に二の足を踏んでいる企業様においても、カジュアルに試すことができるのは大きな魅力の一つだと思います。

6. おわりに

本記事では、Microsoft 365のCopilot Chatを活用した障害対応効率化のPoCについて紹介しました。

当初の理想であった完全自動化こそ実現できませんでしたが、一部分の実現であっても、生成AIを活用した業務改善は十分に可能であることを実感しました。SharePointにドキュメントを格納し、Copilot Chatのナレッジとして登録するだけで、自社の業務に特化した生成AIを構築することができます。この手順自体は、エンジニアでなくても十分に実行可能です。

まずは身近な業務課題をひとつ選び、Copilotに相談してみるところから始めてみてはいかがでしょうか。

1. はじめに
1. 踏み台EC2の課題
2. セッションマネージャーを使用した構成
3. セッションマネージャーの利点
4. まとめ

はじめに

アプリケーションEC2への接続手段として、従来は「踏み台EC2（Bastion Host）」を構築してSSH接続する方法が一般的でした。
しかし、現在はその手法は必ずしも効率的とは言えなくなっています。

現在はAWS Systems Manager Session Manager（SSM セッションマネージャー）を利用することで、踏み台EC2を置かずに、安全かつ低コストでアプリケーションEC2を操作できます。

本記事では、「コスト」「セキュリティ」「運用負荷」の3つの観点から、なぜ踏み台EC2からセッションマネージャーへ移行すべきなのか、その具体的な理由を解説します。

1. 踏み台EC2の課題

図1のように、踏み台EC2を経由して目的のアプリケーションEC2へアクセスする構成はよく見られます。しかし、この方式を維持し続けるには、「コスト」「セキュリティ」「運用負荷」の3つの観点でデメリットがあります。

図1

コスト面の課題

踏み台EC2を維持・管理するために、年間およそ$102（約16,000円）の固定費がかかります。

踏み台EC2の稼働コスト

• 常時稼働する必要があり、年間およそ$58.75（約9,000円）のコストがかかります。
• ※ 30日 × 24時間 × 1時間あたりの料金 0.0068 USD × 12ヶ月 = 58.75 USD（年間）1ドル154円で換算。参考：Amazon EC2 オンデマンド料金（東京リージョン）

• 固定IPを利用する場合、年間およそ$43.2（約6,600円）の追加コストがかかります。
• ※ 30日 x 24時間 x 1時間あたりの料金 0.005 USD x 12ヶ月 = 43.2 USD（年間）1ドル154円で換算。参考：Amazon VPC の料金

• OSの更新や、セキュリティパッチの適用などのサーバ保守に人件費が発生します。

セキュリティ面の課題

踏み台EC2自体が、攻撃対象となるリスクを抱えることになります。

ポートの常時開放

• 踏み台EC2のセキュリティグループでSSHポート（通常は22）を開放する必要があります。
• ブルートフォース攻撃やポートスキャンの標的になり得ます。

• SSH鍵の紛失や不適切な共有がセキュリティホールになる恐れがあります。
• SSH鍵のローテーションを設定・管理する必要があります。

• 踏み台EC2にログインした後のコマンド履歴は、OS側にしか残りません。
• 権限を持つ利用者であれば、ログの改ざんや消去が可能です。

運用面の課題

管理すべきリソースが増えることで、運用担当者の負担が増加します。

管理対象の増加

• 踏み台EC2のメンテナンス負荷がかかります。

• 操作ログをS3やCloudWatch Logsへ転送するためには、追加の設定や実装コストがかかります。

• プロジェクトメンバーの増減に伴い、「鍵の回収」やOS内にて「アクセス権の剥奪」を手動で行う必要があり、作業ミスのリスクが考えられます。

2. セッションマネージャーを使用した構成

図2は、踏み台EC2を使用せずに、セッションマネージャーを使用した構成例です。決済処理などの外部システム連携が必要な一般的なWebサービスを想定しています。

図2

セッションマネージャーは、AWS Systems Managerの機能の一つで、SSHを使わずにEC2やECSへ安全に接続できるマネージドサービスです。

最大の特徴は、アプリケーションEC2側のインバウンドポートを完全に閉じられる点にあります。
これは、EC2内のSSMエージェントがセッションマネージャー側へリクエストを取りに行く「プル型」の通信モデルであるためです。

エージェントはセッションマネージャーに接続要求が来ていないか、アウトバウンド通信で定期的にポーリングしています。一度セッションが確立されると、双方向の通信により、コマンドリクエストを処理します。

またアクセス権限はIAMで一元管理されるため、従来の踏み台EC2が抱えていた「鍵管理」の問題を解消します。

操作ログについても、図3のようにセッションマネージャーの設定画面からログ出力を有効にするチェックボックスにチェックを入れるだけで、簡単にCloudWatch LogsやS3へ統合できます。

図3

3. セッションマネージャーの利点

コスト面の利点

踏み台EC2のコスト面の課題で紹介した、年間およそ$102（約16,000円）の固定費を削減できます。

• EC2の常時稼働コストとElastic IPのコストが不要になります。
• メンテナンスにかかる人件費が削減されます。

セキュリティ面の利点

不要な攻撃対象が減り、監査対応もしやすくなります。

インバウンドポートの完全閉鎖

• ポートスキャン・ブルートフォース攻撃などのリスクを排除します。

信頼性を担保するAWSのログ管理

• IAMによるアクセス制御に加え、CloudTrailでユーザごとのアクセス履歴を記録できます。
• ログがOSから切り離されAWS側で保管されるため、アプリケーションEC2へのアクセス権を持つユーザであっても操作ログの改ざんが不可能になります。
• CloudWatch Logsとの連携も容易です。OS上の実行コマンドだけでなく、あらゆる操作ログを集約できるため、一元管理に非常に役立ちます。

鍵管理の撤廃

• 鍵の配布、紛失、ローテーション、プロジェクト離脱者の鍵回収といった「鍵のライフサイクル管理」に伴うセキュリティリスクが消失します。

運用面の利点

接続体験の向上

• マネジメントコンソール上でのクリック、あるいはAWS CLIによるワンコマンドで即座に接続が完了します。

アカウント管理の統合

まとめ

これまで一般的だった踏み台EC2による運用は、「コスト」「セキュリティ」「運用負荷」のすべてにおいて負担が大きいものでした。セッションマネージャーへ移行することで、これらの課題を解消し、より安全で効率的なインフラ運用が可能になります。

一方で、OSの制約でエージェントをインストールできない場合や、大容量のデータ転送で高いスループットが要求されるなど、特殊な要件がある場合には、踏み台構成を採用することもあります。

しかしその場合でも、踏み台EC2自体へのアクセスにはセッションマネージャーを利用したり、Fargateを踏み台として利用したりすることで、セキュアな構成を維持できます。
（Fargateを踏み台にした場合は、同様な仕組みであるECS Execを使用することで、安全な接続が可能です）

従来の「踏み台EC2＋SSH鍵管理」を利用している場合は、セッションマネージャーへの移行を検討してみてはいかがでしょうか。まずは開発環境などの、影響の少ない環境から試してみるのがおすすめです。

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

目次

はじめに

みなさんこんにちは。インフラエンジニアの伊達です。
やはり何事もコストは最小限で済ませたいものですよね。
システムは大きな問題もなく安定稼働を続けているものの、
インフラ費用をもう少し抑えられないものか気になっている...。
そういったお悩みを抱えている企業様向けに、弊社ではSREのサービスを行っております。
進め方のイメージとともにご紹介していきます。

進め方概要

コストの削減について、以下のようなステップで進めていきます。

ステップ① コスト削減

コスト削減のご相談をいただいたら、まずは現状の把握を行い、削減可能な箇所を特定します。
改善が可能であれば、ご提案させていただく改善策を実施することでコスト削減を実現します。

コスト最適化支援

スペックの高いリソースを使ったり、多くの通信を行ったり、大量のデータを保存したりすれば、コストがかかるのは自然なことです。
しかしそれらが必要以上のスペック、過剰な冗長化に伴うデータ同期の通信、不要なデータの保存などであればコスト削減のポイントになります。
現状の環境にそのような点がないか確認し、改善策をご提案させていただきます。

施策実施

ご提案した改善策にご納得いただき実施することになった場合、「SRE伴走支援サービス」にてご支援させていただきます。実施については、貴社またはご担当ベンダー様にて行っていただくことも、ご要望があれば弊社で行うことも可能です。

ステップ② 継続運用の体制を構築

ステップ①でのコスト削減は、あくまで一回限りの対処です。
その後もシステムは稼働を続けるため、継続して正常に運用することが重要であり、そのための体制が必要です。

運用設計支援

ステップ①でコスト削減を実施しても、その後放置しておけば状況は変化していくものです。
システムが稼働している環境もそれを利用するユーザも毎日同じではありません。
常にコストを監視して、異常に気づける仕組み・体制を作っておく必要があります。
どのリソースをどう監視するか、コスト監視の運用設計を支援させていただきます。

監視基盤構築

Cost Anomaly Detectionを活用してシステムを監視し、「異常」と判断された場合にアラートを出す仕組みを構築します。
コスト異常の早期発見・早期対応が可能となり、不要な支出が継続する事態を未然に回避できます。
これには、アラートを受け取り対処を行うための体制も必要となります。

AWS Cost Anomaly Detection とは

AWS Cost Explorerを日々注意深くチェックすればコストの異変に気付くことも可能ですが、 AWS Cost Explorerの機能である AWS Cost Anomaly Detection を使えば自動的に「いつもと違うコスト増加」を検出することができます。
機械学習モデルを用いることで人間では見落としがちな変化に対する警告が出せることに加え、常時監視という人手では難しい運用ができるため是非とも設定しておきたい機能です。

参考（公式）：https://aws.amazon.com/jp/aws-cost-management/aws-cost-anomaly-detection/

ステップ③ 予防処置の体制を構築

ステップ②で「コスト異常が発生したら」アラートを出すように設定し、それを受けてすぐに対処できる体制を組む話をしました。
しかし、そもそも「コスト異常が発生しない」ように兆候を検知し、事前に対処できる仕組みを構築できれば、対応が後手に回る頻度を減らすことができます。

運用設計支援

サービスコントロールポリシー (SCP)を適切に設定することで、利用を想定していないサービスのリソース作成を制限できます。

AWS Budgetsを活用することで、予算管理を行いコストが想定よりかかる「予測」となった時点で通知を出せるため、
実際にはまだコスト異常が発生していない段階での対応が可能です。
こうした未然防止のための運用設計を支援させていただきます。

AWS Budgets とは

予算管理として設定した予算や閾値に基づいて、コストを監視してアラートを出したり、自動的にアクションを行ったりもできるサービスです。
また、「使用量」に関する監視も行えます。
金額が絶対的に大きいと「無駄を含んでいるのでは...？」と自然に疑うことができますが、中には一見しただけでは判別しにくい「見えない無駄」も存在します。
コストを抑えるつもりでリザーブドインスタンスやSavings Plans を購入したものの、
実はその後想定していたほど使われていなかった、というケースを考えてみましょう。
その場合、支出額自体は増加しないため、「コスト」だけ見ていても気付くことができません。
なぜ使われなくなったのかという原因分析は後で行うにしても、少なくとも次の更新時にはオンデマンドに戻すなど何かしらの対応が必要になります。
AWS Budgetsでリザーブドインスタンスや Savings Plans の利用率に対して閾値を設定しておくことでそのような事態にも早い段階で気付くことができます。

参考（公式）：https://aws.amazon.com/jp/aws-cost-management/aws-budgets/

AIを活用した予兆検知基盤構築

ここまで挙げてきた例などは構成によらない一般的な話でした。
紹介したサービスの中でも既に機械学習を活用しているものがありますが、
将来的にはAIによる判断を最大限に活用しそれぞれの環境に最適化することで、
AWS標準機能では捉えきれないような環境固有のコスト異常の兆候を検知できる監視AIシステムも作れるかもしれません。

おわりに

最後の話はまだ将来の可能性の段階で、今すぐに実現できるものではありませんが、
現時点でできることもたくさんあるはずです。
まずは現状の確認から始めてみてはいかがでしょうか？

1. はじめに
2. 復旧キーとは？
3. 「復旧キーがない場合」を試す
4. まとめ

はじめに

先日、私用のMacBook Proにログインできなくなる問題が発生しました。
経緯としては、2台あるMacBook Pro AとMacBook Pro Bを取り違えてしまい、MacBook Pro AにMacBook Pro Bのパスワードを入力し続け、パスワード入力の試行可能回数を超過してMacBook Pro Aにロックがかかりました。

Macのログインパスワードを忘れた場合に従って、再起動やリセットオプションを使おうとしても「アカウントはロックされています」や「復旧キー入力してください」と表示され、復旧キーが分からず次に進むことができません。
そこで、Appleサポートに問い合わせたところ、設定した「復旧キー」が入力できない場合は、「復旧キーがない場合」を試すか、MacBook Proを出荷時の状態に初期化するしかないことわかりました。
初期化はなんとしても避けたく「復旧キーがない場合」を試してみたので、同じような状況になってしまった方の参考になれば幸いです。

復旧キーとは？

そもそも「復旧キー」とは一体何者なのか分からなかったので調べてみました。

macOS復旧キーとは、ログインパスワードを忘れた際にディスクの暗号化を解除しデータを守るためのパスワード（24桁の英数字）です。（※この復旧キーは、Apple Accountの復旧キー（28桁の英数字）とは別のもので、macOSに標準搭載されている高性能なディスク全体暗号化機能「FileVault」の復旧キーです。）

FileVaultの利用用途はMacでのFileVaultの仕組みによると以下のように記載されています。

Macに機密情報が保存されている場合（例えば、会社の財務情報をお使いのMacノートブックに保存して持ち歩いている場合など）、FileVaultを使用して、ファイルを保護し、ほかの人が機密データにアクセスしたり機密データをコピーしたりできないようにすることができます。

また、FileVault復旧キーの設定の方法はこちらに手順があり、手順の中には以下のような警告がありました。

警告: 復旧キーは忘れないようにしてください。FileVaultをオンにして、ログインパスワードを忘れてリセットできず、復旧キーも忘れてしまった場合は、ログインできません。自分のファイルと設定は永久に失われてしまいます。

そんな大切なキーを私は忘れてしまい、メモや写真を遡っても家中どこを探しても見つかりませんでした。（MacBook Pro Aを購入したのが約5年前でキーを設定した記憶すら曖昧です...）

「復旧キーがない場合」を試す

忘れてしまった復旧キーを探し出すべく、「復旧キーがない場合」の以下の手順に沿って進めます。

復旧キーを入力するMacにmacOS Tahoe 26以降が搭載されている場合は、以下の方法を使うと、ほかのデバイスのパスワードアプリで確認できる可能性があります。

1.iPhone、iPad、別のMacなどのほかのデバイスで、復旧キーを入力するMacと同じApple Accountにサインインしていることを確認し、そのデバイスで「パスワード」を開きます。

2.「パスワード」の「検索」フィールドに「復旧キー」と入力します。

3.検索結果に、復旧キーを入力するMacの名前が表示されたら、その名前を選択し、「復旧キー」フィールドのドットをタップ／クリックすると、Macのキーが表示されます。

今回は、MacBook Pro Bを使ってパスワードアプリからMacBook Pro Aの復旧キーの取得を試みます。

まず、前提としてMacBook Pro BにはmacOS Tahoe 26以降が搭載されている必要があるので「MacのmacOSをアップデートする」手順に従ってmacOSをSequoia 15.5からTahoe 26.2にアップグレードしました。

続いて、システム設定の左側メニュー「サインイン」でApple IDでサインインします。

サインインできたら、パスワードアプリを開いて「検索」フィールドに「復旧キー」と入力します。すると、MacBook Pro Aが表示され復旧キーを確認することができました！

ログインできなくなっているMacBook Pro Aの電源を落とした後、再び電源ボタンを長押して「起動オプションを読み込み中...」が表示されるまで電源ボタンを約10秒ほど押下し続けます。表示される「オプション」を押下し、その下に表示される「続ける」ボタンを押下すると以下の画面に遷移します。

「すべてのパスワードをお忘れですか？」を押下すると、復旧キーの入力画面になるので、先程取得したMacBook Pro Aの復旧キーを入力します。すると、パスワードの再設定画面に遷移し、パスワードを再設定のうえ再起動すると、無事にMacBook Pro Aにログインすることができました！！

まとめ

改めて当初の状況を振り返ると、いつも入力しているパスワードで突然ログインできなくなり、何度もパスワード入力を試行している段階で、2台あるMacBook Proを取り違えていることにもっと早く気付けていれば良かったと思います。
（今回のトラブルを機に、MacBook Proにステッカーを貼り、待受画面も変更しました。また、判明した復旧キーは書き留めて金庫に保管しました。）

Appleのデバイスには、待ち時間の延長によって総当たり（ブルートフォース）攻撃を抑制する仕組みがあり、無効なパスコード、パスワード、またはPIN（デバイスとデバイスの状態に応じて）が入力された場合、次の入力までの待ち時間が1分間、5分間、15分間、1時間...と延長されます。これは、盗難や紛失などで第3者によるログインを防ぐための仕組みで、FileVaultの設定がある場合は最大30回の試行が可能で、それ以上間違えると今回のケースのように「復旧キー」がないとログインできなくなります。

万が一、同様のトラブルに見舞われた際は、諦めてMacBook Pro初期化する前に上記の手順をお試しください。