参画2日目の打ち合わせで、クライアントのチームから「ログインはKeycloakに全部まとめたいんです。いつ切り替えられますか」と聞かれました。答えようと各システムの管理画面を開くと、以前の作業用アカウントがまだ並んでいます。Keycloakの案件に業務委託で参画するエンジニアは、最初の数週間で「この人に任せて大丈夫か」と思われないか、気になるのではないでしょうか。認証の移行は、新しい入口を作る仕事であり、古い入口を閉じる仕事です。

1. Keycloakの案件で任される仕事の範囲

ログインを集める型と、SSOを入れ直す型

Keycloakは認証・ID管理に使われるOSSで、案件名にも製品名が並びます。ただし、製品名が同じでも仕事の中身は一つではありません。ここでは書き手の見立てとして、案件を2つの型に分けて考えます。

1つ目は、システムごとにばらばらだったログインを1か所に集める型です。各システムが持っていたIDとパスワードを、認証の窓口にあたるIdPへ寄せていきます。2つ目は、すでにSSOが動いている環境を入れ直す型で、既存の仕組みから新しい仕組みへ移し替えます。

どちらの型でも、参画する側が最初に見るのは製品の機能一覧ではありません。連携するシステムが何台あり、それぞれがどんな方式でログインを受け付けているかが、作業量と段取りを決めます。デジタルアイデンティティの基本である認証・認可・ID管理の整理は、デジタルアイデンティティの案件の記事にまとめています。

任される範囲を4つの層で見る

案件で任される範囲は、連携先システムの洗い出し、連携方式の選定、移行の段取り、切り替え後の運用の4層に分けると整理できます。これも書き手の見立てで、案件によって含まれる層は異なります。層ごとに成果物を決めておくと、クライアントとの間で「どこまでが自分の仕事か」を合わせやすくなります。

図の作成：Remogu編集部。書き手の見立てを整理したもので、統計データではありません

この4層のうち、技術者が得意としやすいのは前半の洗い出しと方式の選定です。一方で、後半の段取りと運用の取り決めは、システムの外側にある合意事項を多く含みます。製品の設定を覚える前に、この後半で何を決めるかを知っておくと、参画初期の打ち合わせで答えられる範囲が広がります。

では、認証の領域で公的な基準はどんな整理をしているのでしょうか。次の節では、政府機関向けのガイドラインの記述を手がかりにします。

2. 政府機関向けの基準でも認証の強化が改定内容に挙がっている

政府機関等向けのガイドラインであること

この記事で手がかりにするのは、国家サイバー統括室が公表している「政府機関等の対策基準策定のためのガイドライン（令和7年度版）」です。名前のとおり、政府機関等が自分たちの対策基準を定めるための文書で、民間企業に義務を課すものではありません。Keycloakの案件の決まりを書いたものでもありません。

そのため、以降の記述は「政府機関向けの基準ではこう整理されている」という範囲で読んでください。民間の案件に当てはめて考える部分は、すべて書き手の見立てです。ガイドラインの文言を、クライアントが守るべき条件のように読み替えることは避けたいところです。

ガイドラインの手がかりとしての価値は、認証や識別コードの管理について、公的機関が項目に分けて整理している点にあります。クライアントとの打ち合わせで確かめる項目を考えるときの、一つの目安として使えます。境界の内と外を分けない考え方との関係は、ゼロトラストの案件の記事で扱っています。

認証の強化と認証連携の位置づけ

ガイドラインの改定履歴には、改定内容の一つとして「多要素認証等の主体認証の強化」が挙げられています¹。主体認証とは、システムを使う人や機器が本人であることを確かめる仕組みの総称です。改定履歴に載っているのは項目名で、強化の具体的な中身までは、この記事で扱う範囲では確認できません。

もう一つの手がかりは、同じガイドラインの解説にあります。主体認証が必要になる場面が多岐にわたる情報システムでは、認証連携を適切に用いて業務の効率化を図ることも考えられる、という記述です²。あくまで考え方の例示で、導入を求める文言ではありません。

2つを並べると、認証を強めることと、認証を連携させて場面ごとの手間を減らすことが、同じ文書の中に別々の項目として出てきます。ログインを1か所に集める案件は、この2つの項目が重なる仕事だと読めます。ただし、この読み方は書き手の見立てです。

項目	中身
改定履歴に挙がる改定内容の一つ	多要素認証等の主体認証の強化1
認証連携の考え方	主体認証が必要になる場面が多岐にわたる情報システムでは、認証連携を適切に用いて業務の効率化を図ることも考えられる2

上の表は、ガイドラインの記述を2項目に分けて並べたものです。上段は改定履歴に挙がった項目名、下段は解説にある考え方の例示で、出てくる箇所が異なります。どちらも政府機関等が対策基準を定める側に向けた文書であることを、読むときの前提にしてください。

次の節では、実際の移行案件で最初に確かめる項目として、連携方式を取り上げます。

3. 最初に確かめるのは連携方式

ガイドラインの留意項目に含まれる連携方式

ガイドラインは、政府機関等のクラウドサービス管理者が識別コードの作成から廃棄までの管理を定める際に留意する項目として、シングルサインオンを行う場合の連携方式を含めています²。ここで述べられているのは、留意する項目の中に連携方式が入っているという点までです。どの方式を選ぶかは、この資料からは分かりません。

Keycloakは自前で運用するOSSの場合もあるため、ガイドラインのクラウドサービスの解説をそのまま当てはめることはできません。項目の並びを、移行案件で確かめる観点として借りるのが、ここでの書き手の見立てです。連携方式は、OIDCやSAMLのような方式の例が思い浮かびますが、どれを使うかは連携先と案件ごとに異なります。

連携先ごとに確かめる流れ

連携先のシステムごとに、確かめる順番を決めておくと抜けが出にくくなります。対象のシステムを特定し、そのシステムが対応している連携方式を確かめ、切り替える順番を決め、うまくいかなかったときに戻す手順を用意します。これは書き手の見立てによる順序です。

図の作成：Remogu編集部。書き手の見立てを整理したもので、統計データではありません

この流れで特に見落とされやすいのは、最後の「戻す手順」です。新しい認証に切り替えたあとでログインできないシステムが出たときに、どこへ戻せるのかを先に決めておくと、切り替え当日の判断が軽くなります。クライアントとは、戻す条件と戻す権限を持つ人を、事前に協議しておく形が取れます。

連携方式の確認が終わると、次に問題になるのは、構築の過程で作られたアカウントです。

4. 構築で使ったアカウントの後始末を最初に決めておく

構築時に利用した識別コードの扱い

連携方式と同じ留意項目には、構築時に利用した識別コードの主体認証情報の変更や、識別コードの廃棄も含まれています²。識別コードとは、システムの利用者や機器を区別するためのIDのことです。構築のために作った作業用・管理用のアカウントが、構築が終わっても残り続ける場面を想定した項目です。

注意したいのは、ここで挙げられているのが「構築時に利用した識別コード」に限られる点です。参画者個人のアカウントや、移行前の旧アカウントまで含めて廃棄を求めているわけではありません。アカウント全般の話に広げて読まないようにします。

この項目を移行案件の観点として借りると、参画初期に「構築で使う作業用アカウントは、誰が作り、誰が最後に片付けるのか」を決める根拠になります。これも書き手の見立てで、案件ごとに運用の決まりは異なります。権限を渡す設計と閉じる運用の一般論は、IAM設計の案件の記事で整理しています。

アカウントの種類ごとの後始末

後始末を決める相手は、構築時のアカウントだけではありません。移行案件では、構築時の作業用アカウント、参画者の作業用アカウント、移行前の旧アカウントの3種類が関わります。下の表で、種類ごとの後始末の例を並べました。構築時のアカウント以外の2行は、ガイドラインの記述ではなく、書き手の見立てによる例です。

アカウントの種類	後始末の例	位置づけ
構築時に利用した識別コード	主体認証情報の変更や、識別コードの廃棄2	ガイドラインの留意項目
参画者の作業用アカウント	契約が終わったときの止め方を、事前に決める	書き手の見立て
移行前の旧アカウント	切り替え後の扱いを、移行の段取りに含めて決める	書き手の見立て

表の2行目と3行目は、いずれも「いつ・誰が止めるか」を事前に決めるという共通点があります。冒頭の場面に戻ると、各システムに旧アカウントが並んでいたのは、切り替えの段取りの中で止める順番が決まっていなかったためかもしれません。参画初期のうちにこの3種類を一覧にしておけば、移行の日程を聞かれたときに、止める作業まで含めて答えられます。

では、アカウントを整理して認証をIdPに集めれば、各システムの管理者の問題はなくなるのでしょうか。次の節で確かめます。

5. 集めたあとも各システムのローカル管理者は残る

認証を統合しても未使用のまま残るアカウント

ガイドラインの解説は、情報システムで認証機能を統合している場合、各機器等の管理者権限を持つローカルアカウントは通常の運用では未使用になると述べています²。認証をIdPに集めると、日々のログインは窓口を通るようになります。各システムの内側に持っていた管理者アカウントは、出番が減るという整理です。

ただし、解説は未使用になったところで話を終えていません。未使用になった場合も、デフォルトパスワードのままにしない等の措置が要るとしています²。使わなくなったアカウントは、持ち主の目が届かなくなるぶん、初期の状態のまま取り残されやすいということです。

この解説は「消す」ことを求めているわけではありません。書かれているのは、未使用でも措置が要るという点までです。書き手の見立てとしては、複数のシステムで同じパスワードを使い回さないことも、あわせて決めておきたい項目です。

移行案件で洗い出すローカル管理者

移行の段取りに「ローカル管理者の洗い出し」を入れておくと、冒頭の場面のような状況を避けやすくなります。連携先のシステムごとに、管理者権限を持つローカルアカウントが何のために残っているのかを一覧にします。これは書き手の見立てによる進め方で、案件によって手順は異なります。

図の作成：Remogu編集部。ガイドラインの解説²と書き手の見立てを整理したもので、統計データではありません

洗い出した一覧には、アカウントの名前と、保管している人、パスワードを変えた日を並べます。ここで見つかった初期のままのアカウントは、クライアントの管理者と相談して扱いを決めます。参画者が自分の判断で触るのではなく、協議したうえで進める形です。

次は、外部の立場で入る人自身の権限とログの話です。

6. 外部の立場で入る人の権限とログ

委託先に求める対策の例

ガイドラインは、政府機関等が委託先に求めることが考えられる対策の例を挙げています。その一つが、管理者権限を持つ場合には必要最低限の権限と利用に制限したうえで、ログを取得することです²。主体は政府機関等で、求める側の例示にあたります。

業務委託で参画するエンジニアは、この「委託先」の立場に重なります。ただし、民間の案件で同じ対策を求められると決まっているわけではありません。政府機関向けの基準では、管理者権限を絞ってログを残す考え方が例に挙がっている、と受け取るのが正確です。

書き手の見立てでは、この例は参画初期に自分から話題にできる材料になります。「管理者権限は必要な範囲に絞り、作業のログを残したい」と先に提案すると、クライアントとの間で権限とログの取り決めを始めやすくなる場面があります。

不要になったときの止め方

もう一つ、ガイドラインの別の箇所に、主体が情報システムを利用する必要がなくなった場合の措置の例があります。情報システムセキュリティ責任者が、その主体の識別コードを無効にするというものです²。措置を講じる主体は、政府機関側の責任者です。

民間のクライアントにそのまま当てはめることはできませんが、止める操作を行うのはクライアント側という整理は、参画者にとっても手がかりになります。参画者が自分のアカウントを自分で止めるのではなく、止める段取りをクライアントと一緒に決めておく、という進め方です。これは書き手の見立てです。

下の表に、外部の立場で入る人が事前に決めておきたい項目を並べました。ガイドラインに例がある行と、書き手の見立てによる行を、右の列で分けています。

決めること	例	位置づけ
管理者権限の範囲	必要最低限の権限と利用に制限したうえで、ログを取得する2	委託先に求める対策の例
作業ログの取り方と保管	取得するログの範囲と、保管の方法をクライアントと協議する	書き手の見立て
特権アカウントへの多要素の認証	管理者権限を持つアカウントに多要素の認証を使うかを決める	書き手の見立て
不要になったときの止め方	情報システムセキュリティ責任者が識別コードを無効にする例2。民間では、止める担当と手順を事前に決める	ガイドラインの例と書き手の見立て

表の4行はいずれも、契約を結ぶ前後の打ち合わせで話題にできる項目です。権限とログは入る前に、止め方は終わる前に決めておくと、参画の後半で慌てずに済みます。作業ログの保管の範囲など、書き手の見立ての行は、案件ごとにクライアントの運用に合わせて調整します。

これで、確かめる項目が一通りそろいました。最後に、最初の数週間の順番に並べ直します。

7. 参画初期の信頼は閉じる段取りから生まれる

最初の数週間で確かめる順番

書き手の見立てとして、最初の数週間の確認は5つの項目を順に進める形にまとめられます。連携先と方式を洗い出し、構築時のアカウントの扱いを決め、ローカル管理者を一覧にし、自分の権限とログを取り決め、不要になったときの止め方を合意します。

図の作成：Remogu編集部。書き手の見立てを整理したもので、統計データではありません

順番を決める理由は、前の項目の結果が後の項目の前提になるためです。連携先が分からなければ構築時のアカウントは洗い出せず、ローカル管理者の一覧もできません。自分の権限とログは、そのあとで取り決めます。

新しい入口と古い入口

冒頭の問いに戻ります。「いつ切り替えられますか」と聞かれたときに、切り替えの日程だけを答えるエンジニアと、古い入口を閉じる日程まで答えるエンジニアとでは、クライアントが受ける印象は変わります。後者は、ログインを集める作業の外側にある合意事項まで見ている人に映ります。

認証の移行は、新しい入口を作る仕事であり、古い入口を閉じる仕事です。連携方式の確認も、構築時のアカウントの後始末も、ローカル管理者の洗い出しも、自分の権限とログの取り決めも、古い入口を閉じる段取りの一部です。技術の腕とは別に、この段取りを先に口にできるかどうかが、参画初期の信頼につながります。

Remogu（株式会社LASSIC運営）は、リモートワーク案件特化のエンジニアマッチングで、案件の90%以上がフルリモート可能です。認証基盤の経験を生かせる案件に参画したいときは、まず登録して、自分の経験に合う条件を確かめてみてください。

8. よくある質問

Keycloakを触った経験がまだ少なくても、認証基盤の案件に参画できますか

書き手の見立てでは、製品の操作経験よりも、連携方式の理解とアカウント管理の経験が問われる場面があります。製品名が同じでも、案件によって求められる範囲は異なります。別のIdPや認証基盤で連携先を洗い出した経験があれば、その経験を言葉にして伝えられるようにしておくとよいでしょう。

フルリモートで認証基盤の作業をするとき、何を先に決めますか

書き手の見立てでは、接続経路、作業に使う端末、権限の範囲の3つをクライアントと協議して決めます。認証基盤は組織の根っこにあたるため、どこから、どの端末で、どこまで触れるのかを最初に合わせておくと、参画後の手戻りが減る場面があります。権限の範囲は、本文の表で整理した項目と重なります。

移行が終わったあと、参画者が持っていた権限はどうなりますか

政府機関向けの基準では、主体が情報システムを利用する必要がなくなった場合に、情報システムセキュリティ責任者がその識別コードを無効にする例が挙げられています²。民間の案件でも、止める操作を行うのはクライアント側であることが多いと考えられますが、これは書き手の見立てです。契約前に、止める時期と段取りをクライアントに確かめておきたいところです。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 国家サイバー統括室「政府機関等の対策基準策定のためのガイドライン」（2026年6月12日・2026年10月確認）
＊2 国家サイバー統括室「政府機関等の対策基準策定のためのガイドライン」（2026年6月12日・2026年10月確認）