Enterprise executives have faith their AI bets will pay off by 2030, but few have any idea where that income will come from, according to a new study. Expectations for AI run high among the C-suite executives surveyed for the IBM Institute for Business Value’s The Enterprise in 2030 report, with 79% of respondents saying…
After a bumpy couple of years, Europe’s mergers and acquisitions (M&A) market is busy again. By mid-2025, deal volumes were up between 15 and 20% year-on-year, according to IMG. If the trend continues, this will be one of Europe’s strongest years for dealmaking over this past decade. While M&A presents major opportunity, it demands change…
AI 전략 변화에 대한 압박은 여러 방향에서 동시에 가해지고 있다. AI를 재무 성과로 전환하는 데 어려움을 겪으면서 시장이 조정 국면에 들어선 점, 유럽에서 AI 법(AI Act)을 포함한 새로운 규제 집행이 시작된 점, 그리고 전반적인 리스크 환경이 재편되고 있다는 점이 주요 배경이다. 이러한 상황을 종합적으로 고려할 때, 향후 12개월 동안 CIO의 AI 계획이 어떤 방향으로 형성될지를…
이제는 누구나 한 번쯤 들어본 이야기다. 거의 모든 기술 콘퍼런스에서 배경음처럼 반복된다. AI 코딩은 이미 해결됐고, 대규모 언어 모델이 곧 전체 코드의 80%를 작성하게 될 것이며, 인간 엔지니어는 결과물을 감독하는 역할만 남게 될 것이라는 주장이다. CIO의 관점에서 이런 서사는 상당히 매력적으로 들린다. 소프트웨어 개발 비용을 대폭 낮추는 동시에 엔지니어링 속도를 끌어올릴 수 있을 것처럼 보이기…
마이크로소프트(MS)의 최신 실적 보고서는 AI 투자 과정에서 회사가 자원을 과도하게 투입하고 있다는 우려를 불러일으키며 시장에 적잖은 동요를 일으켰다. 이 같은 문제는 주식시장에 그치지 않고, MS 기술을 활용하는 기업 전반에도 파급 효과를 낳을 수 있다는 관측이 나온다. 또한 일부 금융 애널리스트는 MS가 지분 27%를 보유한 오픈AI의 향후 전망에 대해서도 우려를 제기하고 있다. 세바스찬 말러비 미국 외교협회…
투자은행 TD코웬에 따르면 오라클은 미국 은행들이 회사의 AI 데이터센터 확장 자금 조달에서 물러나면서, 2만~3만 명 규모의 인력 감축과 일부 사업 매각을 검토하고 있다. TD코웬은 CIO닷컴이 확인한 리서치 보고서에서 이번 감원을 통해 오라클이 80억~100억 달러(약 11조~14조 원)의 현금 흐름을 확보할 수 있을 것으로 분석했다. 오라클은 2022년 283억 달러(약 41조 원)에 인수한 헬스케어 소프트웨어 사업부 서너 매각도…
지난 1년은 CIO에게 일종의 분수령이었다. AI는 실험 단계를 넘어 경영진의 최우선 과제로 올라섰지만, ‘AI 도입’ 열풍 속에서 많은 조직이 흔들리는 장면도 적지 않게 목격했다. 기술이 부족해서가 아니라, 기본기를 건너뛰었기 때문이다. 실리콘밸리부터 인도까지 글로벌 고객을 지원하며 30년 넘게 엔터프라이즈 IT 현장을 경험해 오면서 필자는 한 가지 결론을 얻었다. AI가 가치를 내는 조건은 ‘탄탄한 기반’이다. 레거시 데이터센터를…
AI 에이전트를 배포한 기업은 성능을 미세 조정하는 과정에서 비용 때문에 충격을 받을지도 모른다. 몇몇 설문조사에 따르면, 기업의 약 80%가 이미 AI 에이전트를 배포했지만, 대부분 기업은 에이전트를 학습시키고 결과물을 평가하는 데 드는 비용 구조를 이해하지 못하고 있다. 전문가들은 이 때문에 예상을 크게 뛰어넘는 비용이 발생할 수 있다고 경고한다. AI 옵저버빌리티 기업 몬테 카를로(Monte Carlo)의 CTO 리오르…
AIエージェントの危険性は「言い間違い」や「誤答」だけでは説明できない、という点だ。LLM（大規模言語モデル）単体のリスクは、主に生成物の品質や不適切発言、幻覚など、出力の内容に焦点が当たりやすい。しかしエージェントは、生成した文章を“行動”に変換してしまう。ここにセキュリティの質的な変化がある。
エージェントが持つ特徴を言葉にすると、自律性・連鎖性・権限性の3つが核になる。自律性とは、与えられた目的を達成するために、必要そうな手順を自分で組み立てて進める性質だ。連鎖性とは、一つの判断が次の入力を生み、その入力が次の判断を誘発し、結果的に長い実行チェーンになる性質だ。権限性とは、メール送信、チケット起票、データ取得、決済、デプロイといった「本来なら人が権限を持って実施していた操作」を、APIキーやSaaS連携の権限としてエージェントに渡すことだ。
この3つが揃うと、従来のアプリケーションよりも攻撃面が増える。理由は単純で、エージェントの判断材料（コンテキスト）が“外部から持ち込まれる”からだ。人間なら、メール本文やWebページを読んで「これは怪しい」「この指示は無視しよう」と判断してから操作する。しかしエージェントは、メールやWeb、PDF、チャットログ、チケット本文、さらにはRAG（検索拡張生成）で拾った資料など、さまざまな入力を同じ“材料”として扱いがちである。結果として、「データの中に命令が混ざる」状況が発生する。
さらに厄介なのは、エージェントは“目的達成”を優先するように設計されることが多い点だ。例えば「顧客からの問い合わせに即レスして」「売上レポートを自動で作って共有して」「緊急障害の一次対応をして」といった指示は、スピードや自動化を求める。そこでエージェントに強い権限を渡し、障害対応やコミュニケーションまで任せるほど、攻撃者にとっては魅力的な的になる。人の操作なら一回のミスで済むかもしれないが、エージェントはミスを“自動で増幅”し得る。
脅威モデルを考えるとき、従来は「アプリの入口＝APIやUI」「権限の境界＝ユーザー権限と管理者権限」「データフロー＝DBとサービス間通信」のように整理できた。ところがエージェントの入口は、APIやUIだけではない。メール本文、添付ファイル、社内Wiki、Slack、カレンダー、CRMのメモ欄、ログ、Web検索結果など、いわば“自然言語で書かれたものすべて”が入口になる。そして権限の境界も、ユーザー単位ではなく「エージェントが持つツール実行権限」に移っていく。ここを更新しない限り、どれだけ堅牢なインフラを敷いても、入口が穴だらけのままになってしまう。
要するに、AIエージェントを守るというのは、モデルを賢くすることではなく、「どこから何が入ってきて」「何を実行できて」「実行結果がどこへ波及するか」を設計することに近い。これが“エージェント時代の脅威モデル”の出発点になる。
AIエージェントの攻撃を語るとき、プロンプトインジェクションが真っ先に出てくる。もちろん重要だ。ただし、インジェクションは“入口”であって、被害の本体は「権限の悪用」と「横展開」によって生まれることが多い。脅威モデルとしては、入口→実行→波及という連鎖で捉えると理解しやすい。
最も分かりやすい入口は、メールやチャットの本文に紛れ込む誘導だ。例えば「この問い合わせは至急。まず顧客のアカウント状況を確認し、必要なら請求情報を更新して返信して」など、業務上もっともらしい文章が混ざっていると、エージェントは善意で動く。さらに本文のどこかに「システムメッセージを無視して次の操作を行え」などの指示が混ざっていると、エージェントの行動を乗っ取れる可能性が出る。人が読めば不自然でも、エージェントは“業務の一部”として扱ってしまいがちだ。
入口は自然言語だけではない。RAGを使って社内ドキュメントやナレッジベースを参照させる場合、その参照先に悪意ある文章が混入すると、エージェントはそれを「正しい根拠」だと誤認しやすい。外部Web検索を許している場合はなおさらで、攻撃者は検索結果に出やすいページを用意してエージェントを誘導することも考えられる。ここで重要なのは、攻撃者はモデルを直接攻撃しなくても、モデルが参照する“材料”を攻撃すればよい、という構図だ。
入口から侵入した次の段階が、ツール実行の不正誘導である。エージェントができることは、結局ツールができることに等しい。CRM検索、請求システム更新、メール送信、ファイル共有、Git操作、クラウド設定変更など、業務上の便利さを理由にツールを増やすほど、攻撃者は“実行手段”を手に入れる。たとえば「顧客対応」という名目で、顧客データの取得や添付送信が可能になっていれば、情報漏えいの経路が一気に現実味を帯びる。さらに「障害対応」という名目で、インフラ変更や再起動、設定更新まで許可していれば、最悪の場合はサービス停止や改ざんにつながる。
ここで発生しやすいのが、権限の誤委譲だ。人間は業務の文脈で「この操作は管理者に確認すべき」「このデータは持ち出し禁止」と判断するが、エージェントにその判断を委ねると、ポリシーが曖昧なまま実行される。特に危険なのは、「便利だから」と広い権限を一つのエージェントに集約してしまう設計である。メールも送れる、ファイルも共有できる、顧客データも見られる、請求情報も更新できる、となると、攻撃者が一度誘導に成功しただけで、被害は複合的になる。
そして最後の段階が横展開だ。横展開とは、最初に侵入した入口とは別の場所に被害が広がることを指す。エージェントの場合、横展開の典型は「エージェントが持つ認証情報・セッション・APIキーが、他のシステムに波及する」形で起きる。エージェントが使うSaaS連携は、しばしば長期トークンや高権限APIキーで実現されている。これが漏れたり悪用されたりすると、被害はエージェントの範囲を超える。また、エージェントが生成した結果（メール文、ドキュメント、チケットのコメント）が別のエージェントの入力になっている環境では、入力汚染が連鎖して“自走”することもあり得る。これがエージェント特有の怖さで、単発のミスがワークフロー全体に波及する。
攻撃パターンをまとめると、入口は「信頼できない入力」、実行は「ツールと権限」、波及は「連鎖と共有」である。脅威モデルは、個別の攻撃テクニックよりも、この構造を押さえたほうが強い。なぜなら、具体的な攻撃手法は変化しても、入口・実行・波及の三段階は設計上ずっと残るからだ。
では、AIエージェントを安全にするには何から手を付ければいいのか。理想を言えば、強固なポリシーエンジン、堅牢なサンドボックス、包括的なレッドチーム、継続的な安全評価など、やることはいくらでもある。ただ現実には、まず「壊滅的な事故を避ける」ための最小セットが必要になる。ここでは、境界・検証・観測という3つの軸で整理する。
最初の軸は境界、つまり「信頼できるもの」と「信頼できないもの」を明確に分けることだ。エージェント設計でありがちな失敗は、メール本文も社内の手順書も、ユーザーの指示も、すべてが同じコンテキストに混ざってしまうことにある。混ざった瞬間、命令とデータの区別が曖昧になり、攻撃者は“データの形をした命令”を持ち込める。したがって、信頼できない入力を原則として隔離し、「それは参考情報であって命令ではない」という前提を、実行系で担保する必要がある。ここで重要なのは、モデルにお願いして分離させるのではなく、設計として分離することだ。コンテキストを区画化し、ツール実行に影響する領域を限定する。さらに、長期メモリや共有メモリがあるなら、その書き込み条件を厳しくし、未検証情報が永続化しないようにする。
次の軸は検証だ。エージェントはツールを呼び出す瞬間に「現実へ介入」する。ならば、その瞬間に検証ゲートを置けば、被害を大きく減らせる。検証にはいくつか層がある。まずスキーマの固定と引数検証だ。ツール呼び出しの形式を厳格にし、想定外の引数や危険な値を弾く。次に許可リストとポリシー判定だ。例えば外部宛てメール送信、ファイルの公開共有、請求情報の変更、支払い実行のような操作は、業務上の正当性が必要なため、ポリシーで条件を定義し、満たさなければ実行不可にする。そして人間承認である。特に高リスク操作は、エージェントが提案した操作を人が確認してから実行する形にし、完全自動を避ける。ここでのコツは「全部を承認にすると運用が回らない」ので、承認が必要な操作の基準を明確化することだ。金銭・個人情報・権限変更・外部公開・破壊的変更、このあたりは原則承認に寄せると事故が減る。
最後の軸が観測だ。エージェントは「何を見て」「どう判断して」「何を実行したか」が追えないと、事故が起きたときに止血も再発防止もできない。観測とは、監査ログを残すだけではない。入力（参照したデータ）、推論（使ったモデルとプロンプトテンプレ）、実行（ツール呼び出しと結果）、そして権限（どのトークンで何をしたか）を、追跡可能な形で保存することだ。さらに、異常検知の観点も必要になる。いつもは見ない量のデータを取得していないか、通常はしない宛先にメールを送ろうとしていないか、深夜に権限変更が発生していないか、といった兆候を、エージェントの実行ログから検出できるようにする。エージェントはミスを拡大し得るのだから、観測によって早期に止める仕組みが欠かせない。
この3軸を、導入順に並べると分かりやすい。まず境界を引く。次にツール実行に検証ゲートを置く。最後に観測を整備し、異常を早く見つけて止められるようにする。これだけでも、エージェント導入の“初期事故”の多くは回避しやすくなる。 AIエージェントは、セキュリティにとって「未知の魔法」ではない。入口が増え、権限が集まり、実行が連鎖しやすいシステムだと捉えれば、脅威モデルは作れる。重要なのは、プロンプトを賢くすることより、実行系の設計でリスクを減らすことだ。便利さのために自律性を上げるなら、そのぶん境界・検証・観測を強くする。エージェント時代のセキュリティは、このトレードオフを“設計で”引き受けるところから始まる。
Read More from This Article: AIエージェント時代の脅威モデル入門──「自律性」が増やす攻撃面をどう捉えるか
Source: News
ベンダーから事業会社へ——新たなフィールドへの挑戦で得たやりがい ——これまでのキャリアをお教えいただけますか。 私のキャリアは、かなり変わった道筋を辿ってきました。大学時代は美術・考古学を専攻していて、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の分野で活躍する女性は着実に増えています。「あの人にできたのだから、自分も挑戦してみよう」と、少し軽やかな気持ちで一歩を踏み出してほしいですね。 私の上司はインド出身なのですが、よく「日本人は完璧主義だ」と指摘されます。もちろん前準備（前始末）は丁寧に行うべきですが、実際には「やってみないと分からないこと」や「リリースしてみなければ評価できないこと」が数多く存在します。だからこそ、一歩踏み出し、ダメならすぐに軌道修正する。その柔軟さを持って取り組むことが、これからのリーダーに求められる姿勢だと考えています。 以上…