「物語を語れるCIO」であれ——ランスタッドCIOが語るリーダーシップの真髄

ベンダーから事業会社へ——新たなフィールドへの挑戦で得たやりがい ——これまでのキャリアをお教えいただけますか。 私のキャリアは、かなり変わった道筋を辿ってきました。大学時代は美術・考古学を専攻していて、ITとは全く無縁の世界にいたのです。当時は就職氷河期で就職が難しかったのですが、IBMがインターネットを使った美術館のプロジェクトを手がけていることを知り、「これは面白そう」と思って応募したのが、ITの世界に入るきっかけでした。 IBMでは19年間、SEやITアーキテクトとしてさまざまな経験を積み、その後、事業会社での実践的なIT活用に魅力を感じて、ファーストリテイリングでモバイルアプリやECサイトの統括を担当しました。それからセールスフォースでベンダーとしての経験を積んだのですが、やはり「事業会社でITを使って、ビジネスをスケールさせる仕事のやりがい」が忘れられず、アダストリアに移ってECサイトやモバイルアプリ、DX戦略を手がけることになりました。 現在、CIOを務めるランスタッドは人材業界ということで、私にとっては全く新しい業態です。毎日が学びの連続で、驚きと発見に満ちています。これまでは、自分の担当領域だけを見ていればよかったのですが、今はCIOとして「会社全体のシステムに起こることすべてが自分の責任」という重みを感じています。その分、いろいろなことに挑戦できる機会も増えて、とても楽しく仕事をしています。 ECサイトの大規模刷新を経て得た「変革の進め方」 ——これまでのキャリアを振り返って最も大きな実績は何だったのでしょうか。 これまでのキャリアで最も達成感があったのは、前職のアダストリアで手がけたECサイトの大刷新プロジェクトです。データセンターのサーバーからクラウドへの移行、モノリシックなシステムからマイクロサービスへの転換など、複数の大きな改革を5つのフェーズに分けて進めました。 それぞれのフェーズが重なり合う状況で、技術的な難易度はとても高いものでしたが、社員の方々に協力していただいて、なんとか最後までやり抜くことができました。 このプロジェクトから学んだのは、「全てを一気に進めるのではなく、少しずつ切り出して、小さな成功を積み重ねていくこと」の大切さです。そして、「ビジネス側の方々を味方につけるために時間をかけること」の重要性を学んだことも価値ある経験になりました。 実際に現職でも、この学びを生かしています。先週も、ビジネス側の執行役員の方々にお集まりいただいて、「私たちはITを使ったこのような世界を目指しています。一緒にやりましょう」という形で巻き込みを図りました。こうしたアプローチはまさに、前職のプロジェクトで身につけたものです。 現場をIT部門の味方にするために——前職から続く挑戦とは ——実績を上げるための挑戦はどのようなものだったのでしょうか。その学びは現職にどのような形で生かされていますか。 ビジネス側の方々に「アーキテクチャ刷新の価値」を理解していただくのはとても大きな挑戦でした。アーキテクチャの刷新は直接お金につながるものではないので、「なぜ、これをやると良いことがあるのか」を、ビジネスサイドの方々にも分かりやすく説明する必要があったのです。 何度もその価値や思いを伝え続けて、最終的にはビジネス側から「それならマイクロサービスで進めましょう」と言ってもらえるくらいの説明が必要です。もちろん専門領域が違うので説明には時間がかかりますが、そこを面倒くさがらずに、きちんと時間をかけることが良い結果につながります。 今の会社でも同じアプローチを取っており、ビジネス側に「IT導入を応援してくれる人」になってもらうために、情報を積極的に共有していく取り組みを続けています。 キャリアの軸を支える二つの助言 ——これまで受けたキャリア面のアドバイスで印象に残っているものはありますか。 2つありまして、1つ目は、IBM時代に出会った素晴らしいリーダーシップを発揮する女性の先輩からいただいた「目の前に来た馬車には乗れ」という言葉です。新しいことへのチャレンジはとても怖いものですが、「せっかく馬車が来たのだから乗ればいいじゃない」とシンプルに考えて決断すれば良い、と教えてくださいました。今のCIOというポジションにチャレンジしようと思ったのも、この言葉があったからかもしれません。 2つ目は、ファーストリテイリングの柳井社長からの「後始末じゃなくて、前始末をしなさい」という教えです。 「後始末だと時間がかかって後手に回るので、できるだけしっかりと時間をかけて前始末(事前準備)をしなさい」という考え方です。これは完全に自分の中に染み込んでいて、今でもメンバーに「なぜ、前始末ができていないの? もう少し準備に時間をかけましょう」と、ついつい話してしまうほどです。 例えば最近、複数の大きなリリースが重なる時に、「どの環境を誰がどのように使うのか」がはっきりしていない状況がありました。そういう時こそ、面倒くさがらずに関係者と一つひとつ話し合って決めていくという「前始末」が大切です。そうすることで、その後のテストやリリースがとても楽になるのです。 CIOとしてのやりがいは、「外のやり方」を提示することで「新たな選択肢」を示せること 人材業界は私にとって新しい分野なので、毎日いろいろな発見があり、疑問も湧いてきます。異なる領域から来た私だからこそ、「これってどうしてそうなっているんですか?」と素直に聞くことができると思っています。 その上で、「外の世界にはこういうやり方もありますよ」「正解ではないかもしれませんが、こんなアプローチもあるかもしれません」ということを、経営の方々やさまざまな立場の方にお話しできるのは、とてもやりがいがある部分です。「自分が今、この会社で出せる価値は、こういうことなのかな」と感じています。 責任の面では、これまでECやモバイルアプリという特定の領域を見ていたのが、今は「この会社のITに関わるものすべてが自分の肩にのしかかる」という状況になりました。領域は広がりましたが、マインドとしてはあまり変わっていません。ただ、以前は設計まで含めて自分ですべて把握していたものが、今は様々な人に任せている部分を見ることになるので、「一歩引いた上で、その責任をどう背負うか」というところが新しいチャレンジになっています。 CIOに求められるのは「物語を語る力」 ——CIOとしてリーダーシップを発揮する上で大事にしていることは何ですか。 最も重要なのは、「物語を語れること」だと思っています。 ITの話はどうしても難しく聞こえがちですが、「この小さなリリースや機能の先に、皆さんに描ける未来はこれです」ということを伝えた上で、「だから今は、その未来に向けて、この小さなリリースを積み重ねているんです」という話ができると、現場の方々も「それなら、次はこういうことがあるんだ」「こういうことが見えてくるんだ」と思ってくださって、共感していただきやすくなります。 この「物語を語る」ということには、コミュニケーション能力だけでなく、「今後3カ月のリリースではなく、2年先のあるべき姿」を見据えて、どういう段階を踏んでいくかを見極める力も含まれます。これがCIOに必要な資質だと思っていて、私自身もまだまだ磨いているところです。 AIの活用方針は「人間との共存」 ——今やAIは企業戦略に欠かせない存在となっています。どのように活用していくお考えですか。 AIの活用については、正直なところ2025年1月以降に状況が急速に変化しており、どこまで正確にお話しできるか不安な部分もあります。 その上で、弊社では「ヒューマンインザループ」の考え方を基本に据えています。AIにすべてを任せるのではなく、あくまで補助的に活用する。これは日本の法令だけでなく、本社があるEU圏のAI法に準拠する必要があること、そしてAI特有のハルシネーション(誤出力)のリスクを踏まえた判断でもあります。「AIと人間が共存することを大切にする」というのが、私たちの基本方針です。 一方で、日本のIT業界では導入のスピードが加速しています。AIはすでにコーディングに活用できますが、そのコードが正しいかどうかを見極めるのは、まだ人間の役割です。1〜2年後にはそこもAIが担うかもしれませんが、現時点では人間とAIが互いの強みを補完し合っている段階だと感じています。 社内には、AIを「専属エンジニア」のように使いこなしているメンバーもいます。ただ、すべての業務がすぐにAIに置き換わるとは考えていません。深い知見や広い視座、そして「最終的な判断」は人間に残り続ける領域だと思います。 重要なのは、自分にできないことをAIに丸投げするのではなく、自分が理解していることを精度高くAIに指示することです。AIを活かすには「人に伝える力」や「解像度高く要求を伝える力」が不可欠であり、これは生成AIの時代においても変わらず求められるスキルだと考えています。 失敗した時の基本姿勢は「バッドニュースファースト」で ——失敗したときのリカバリーについて、どのような考え方をお持ちですか。 私が常に心がけているのは「バッドニュースファースト」、つまり悪いニュースほど早く伝えるという姿勢です。メンバーにも「悪いニュースを自分のところで留めてしまうと、あなたの責任になってしまう。だから、できるだけ早く私のところに引き上げてほしい」と伝えています。私自身も上司に対しては、速やかに「こんなことが起きました」と共有し、透明性を最優先にしています。 現在の職場は、国籍や文化が異なる方々と仕事をする環境で、同じことを言う場合でも、伝え方次第でネガティブに受け取られてしまうことがあります。そのため、常に相手の反応を見ながら「いつ、どのように伝えるべきなのか」を考え、適切なタイミングでできるだけポジティブな表現に変換して伝えるようにしています。これは文化を問わず有効な方法だと思っています。 また、日本人と海外スタッフではコミュニケーションのスタイルも異なります。部会のような場では一つのメッセージを統一的に伝えますが、1on1の場では少し調整を加えています。「まずは承認されていることを知りたい文化」もあれば、「改善点を先に知りたい文化」もある。そうした多様な価値観を見極めながら対話することを意識しています。 IT改革の第一歩は「紙文化」からの脱却 ——今後、ランスタッドのIT改革をどのように進めますか。 入社してまず驚いたのは、社内に根強く残る「紙の文化」でした。現在は、それらを一つひとつデジタルへと移行することから改革を始めています。 私の頭の中では、進めるべき変革を「10段の階段」に例えています。今年の秋にはその最初の一歩目をリリースする予定です。以降は、標準化にも気を配りながら、日本だけでなくグローバル全体で足並みを揃え、効率的なシステム基盤を共に築いていきたいと考えています。 また、日本でゼロから作り上げるのではなく、海外で開発されたシステムを「これを使わせてもらえますか?」と柔軟に取り入れる工夫も進めています。そうした取り組みを重ね、できるだけ早く「10段の階段」を駆け上がりたいと思っています。 次世代リーダーに求められるのは「完璧主義にとらわれない柔軟な考え方」 ——次世代ITリーダーにアドバイスをお願いします。 私はここに至るまで、すべてが順風満帆だったわけではありません。多くのプロジェクトで失敗や迷惑をかけた経験もあります。それでも今、ここに立っているのは、「責任を背負って頑張る」ことが大切である一方で、「死ぬわけではないのだから、思い切って挑戦してみてもいい」という考え方を持ってきたからだと思います。 CIOという役職には、まだ女性が少ないのが現状です。しかし、ITの分野で活躍する女性は着実に増えています。「あの人にできたのだから、自分も挑戦してみよう」と、少し軽やかな気持ちで一歩を踏み出してほしいですね。 私の上司はインド出身なのですが、よく「日本人は完璧主義だ」と指摘されます。もちろん前準備(前始末)は丁寧に行うべきですが、実際には「やってみないと分からないこと」や「リリースしてみなければ評価できないこと」が数多く存在します。だからこそ、一歩踏み出し、ダメならすぐに軌道修正する。その柔軟さを持って取り組むことが、これからのリーダーに求められる姿勢だと考えています。 以上…

データ漏えいはどこで起きる?AIエージェントの秘密情報管理とログ設計

漏えいの経路を可視化する:入力、メモリ、ログ、外部連携

データ漏えいを防ぐには、まず「秘密情報がどこに存在し得るか」を網羅的に把握する必要がある。AIエージェントの世界では、秘密情報はデータベースの中だけに閉じない。会話、参照資料、要約、実行ログ、学習用データ、キャッシュなど、あらゆる場所に一時的・永続的に残り得る。しかもそれぞれが次の処理の入力になり、意図せず拡散することがある。

最初の経路は入力である。エージェントはメールやチャット、チケット、PDF、社内Wiki、顧客の問い合わせ文などを読み取り、そこから必要情報を抽出して動く。ここで起きる漏えいは単純で、入力に含まれていた秘密情報を、出力やツール実行を通じて外に出してしまう。例えば顧客対応で、問い合わせ文に含まれていた個人情報をそのまま別の宛先に転送してしまう、社内限定の手順書の一部を外部向け返信に混ぜてしまう、といった事故だ。人間なら「この段落は社外秘」と判断して切り分けるが、エージェントは材料を同列に扱いやすい。入力段階で「これは外に出してよい情報か」を識別できない設計だと、漏えいは時間の問題になる。

次の経路がメモリである。エージェントを便利にする機能として、会話履歴の保持や長期メモリ、あるいはRAG用のベクトルインデックスが使われることが多い。しかしメモリは“便利な永続化”であると同時に、“漏えいの温床”にもなる。会話履歴にPIIや契約情報が残れば、後続のタスクで意図せず参照される可能性がある。長期メモリに書き込まれた情報が別のユーザー対応に混入すれば、顧客間の情報混線が起きる。RAGのインデックスに取り込んだ文書が過剰に広い権限で検索されると、本来アクセスできない人が情報を引き出せる。メモリは「いつ」「誰が」「どの条件で」読み書きできるのかを設計しないと、アプリケーションのデータ分離が崩れる。

さらに見落とされがちなのがログである。エージェントシステムは、トラブルシューティングや監査のために多くのログを残す。プロンプト、入力データ、参照したドキュメント、ツール呼び出しの引数、APIのレスポンス、エラー内容などが記録される。しかし、ログは一度残ると長く残り、アクセス範囲が広くなりがちだ。開発者や運用者が調査用に閲覧できるログに、顧客データやAPIキーが混入していると、それ自体が大きな漏えい面になる。さらに、ログが外部の解析サービスやSaaSに転送されている場合、その転送経路もリスクになる。エージェントは観測性が重要だが、観測性のために秘密情報がばらまかれるのは本末転倒だ。

最後に外部連携である。エージェントは外部ツールを使って価値を出す。SaaS、社内API、データウェアハウス、クラウド操作、決済、メール送信、ファイル共有など、連携先が増えるほど漏えいの出口も増える。特に危険なのは、連携のための認証情報をエージェント周辺に置くことだ。長期トークン、広いスコープのAPIキー、共有アカウントの資格情報などが残っていると、エージェントが誤って漏らすだけでなく、攻撃者に悪用される可能性も高まる。外部連携は「データが出ていく」だけでなく、「認証情報が露出する」という二重の意味でリスクがある。

このように、漏えい経路は一つではない。入力、メモリ、ログ、外部連携という四つの通り道を地図として描き、秘密情報がどこで発生し、どこに残り、どこから出ていき得るかを具体的に整理することが第一歩になる。

秘密情報の扱いを標準化する:ポリシーから実装へ

経路が見えたら、次は扱い方を“標準化”する必要がある。秘密情報は「気をつける」では守れない。エージェントが関わる限り、うっかりや誘導、バグ、更新によって必ず揺らぐ。だからこそ、分類とルールを決め、それを実装で強制する形にする。ここで重要なのは、セキュリティチームの規程だけで終わらせず、開発と運用が実際に守れる仕組みに落とし込むことだ。

最初にやるべきは、データ分類である。個人情報、認証情報、契約情報、財務情報、機密ソースコード、営業情報など、漏れると困るものは多い。だが現場で運用するなら、分類は細かすぎても回らない。ポイントは、エージェントが扱える範囲を決めるための分類にすることだ。例えば「外部に送信してよい」「社内限定」「権限者限定」「絶対にログに残してはいけない」のように、扱いのルールと直結するカテゴリに落とす。ここが曖昧だと、後段の技術対策も曖昧になる。

次に、認証情報の扱いを徹底する。エージェントにツールを触らせるなら、必ず認証が必要になるが、長期的に使える固定キーを持たせる設計は避けたい。理想は短命クレデンシャルで、必要なときだけ発行し、短時間で失効させる。権限のスコープも最小化し、読み取り専用と書き込み権限を分ける。可能なら環境ごとに分離し、開発環境のキーが本番に通用しないようにする。秘密情報をプロンプトに直埋めしない、会話コンテキストに混ぜない、エージェントが説明文として吐き出せないようにする、といった基本もここに含まれる。

さらに、データマスキングと最小開示を原則にする。エージェントが顧客データを参照するとき、必要な項目だけを渡す設計にする。例えば本人確認が目的なら、フルの住所やクレジット情報まで渡す必要はない。問い合わせ対応なら、注文番号とステータスだけで十分かもしれない。エージェントのコンテキストに渡した瞬間から、その情報は生成物やログに混入する可能性がある。したがって、エージェントに渡すデータは「最小で、短時間で、目的限定」にするのが基本になる。

この標準化を現実にするには、ポリシーをコードに変換する必要がある。具体的には、ツール実行前のフィルタで引数や送信先を検査し、禁止データが含まれていればブロックする。出力段階でも、外部送信や公開共有が絡むときは検査を強化し、マスキングや警告を入れる。加えて、メモリへの書き込みも制御する。長期メモリに保存してよい情報の条件を限定し、PIIや認証情報が混入する可能性があるものは保存しない。RAGのインデックスに入れる文書も、アクセス制御とセットで管理し、検索結果が不用意に広いユーザーに渡らないようにする。

ここまでの話は「厳しくして便利さを下げる」ように見えるかもしれない。しかし標準化の目的は、便利さを保ったまま事故を減らすことにある。ルールが曖昧なままだと、現場は不安になり、最終的にエージェントを信用できなくなる。標準化は、運用者にとっての安心材料でもある。

ログは武器にも爆弾にもなる:観測性とプライバシーの両立

AIエージェントを業務に入れるなら、ログと監査が重要になる。何かが起きたときに、どの入力が原因で、どのツールが実行され、どこに影響が出たのかを追えないと、インシデント対応ができないからだ。しかしログは、取り方を間違えると最大の漏えい源になる。観測性を上げようとして、秘密情報を記録しすぎる。この矛盾を解くには、ログを「調査に必要な最小限」に設計し直す必要がある。

まず考えるべきは、ログに残すべきものと、残してはいけないものの線引きだ。エージェントの調査で重要なのは、入力そのものの全文よりも、参照元と要点であることが多い。どのメールを参照したのか、どのドキュメントを引いたのか、どの検索結果を使ったのか。ツール実行については、どのツールをいつ呼び、成功したか失敗したか、影響を与える引数は何だったか、が重要になる。一方で、顧客の全文や認証情報、支払い情報、個人の詳細などを丸ごと残す必要はほとんどない。必要なら、マスキングした形やハッシュ化した識別子で追跡できるようにする。ログは「内容」ではなく「証跡」を残す、という発想が鍵になる。

次に、ログ閲覧権限を絞る。エージェント関連のログは、開発者全員が見られる状態になりがちだが、そこに顧客データが混入するリスクを考えると危険である。閲覧は必要最小限のロールに限定し、監査ログで誰が見たかを追えるようにする。保存期間も重要だ。長く残すほど調査には便利だが、漏えい面が増える。目的に応じて期間を分け、短期で十分なものは短く、監査上必要な証跡だけを長期保存する。ここも最初に決めておかないと、いつの間にか無制限に溜まっていく。

さらに、外部へのログ転送に注意する。可観測性のためにログ解析SaaSを使うこと自体は普通だが、そのSaaSに秘密情報が流れる設計だと、リスクが増える。転送前にマスキングを徹底し、そもそも外部に出してはいけない種類のログは出さない。エージェントはモデルプロバイダや外部APIとも通信することが多いので、通信とログの境界が曖昧になりやすい。どこまでが社内で、どこからが外部かを明確にし、外部に出る前に必ずフィルタがかかる構成にする。

ここまで設計しても、インシデント時には「詳細が欲しい」となる。そこで最後の工夫として、平時は最小ログ、非常時は一時的に詳細ログという切り替え設計が有効になる。常に詳細ログを取り続けるのではなく、異常検知や人間の判断で“観測モード”を上げ、短期間だけ詳細を残す。もちろんこの切り替え自体も権限管理が必要だが、プライバシーと調査能力の両立には合理的な選択肢になる。 AIエージェントのデータ漏えいは、特別なハッキングからだけ起きるわけではない。入力に混ざり、メモリに残り、ログに溜まり、外部連携から出ていく。だからこそ、秘密情報を守るには、通り道を地図として描き、分類とルールを標準化し、ログを証跡として設計し直す必要がある。エージェントは便利だが、便利さの裏には必ずデータの移動がある。移動を制御できる設計に変えれば、エージェントは怖い存在ではなく、統制可能な業務基盤として扱えるようになる。


Read More from This Article: データ漏えいはどこで起きる?AIエージェントの秘密情報管理とログ設計
Source: News

CIO코리아·데이터이쿠, 조찬행사 개최···‘에이전트 AI 실행과 거버넌스’ 방향 제시

김종덕 데이터이쿠 지사장은 환영사에서 “지난해 한국에서 조직을 확대하며 다양한 고객사를 확보해왔다”라며 “대기업과 중견기업을 포함해 여러 산업군에서 레퍼런스를 구축하며 고객 지원을 이어가고 있다”라고 밝혔다. 이어 데이터이쿠가 AI와 에이전트 분야에서 기업의 활용을 돕는 솔루션이라고 설명했다. AI 시대에 더 중요해지는 자기주도성 이날 첫번째 발표자로 나선 미래탐험공동체 대표인 장동선 박사는 뇌과학자 관점에서 AI 시대에 인간의 뇌가 왜 더 중요해지는지를…

Zero trust in practice, not theory

Zero Trust has been the industry’s North Star for a decade, yet most enterprises still struggle to operationalize it. The principle “never trust, always verify” is easy to say, hard to do. According to Gartner, 63% of organizations worldwide have implemented some form of zero trust strategy, yet only a small fraction report applying its…