本文へ移動
情シスのミカタ
コラム約8分で読めます

【AI対談】情シスの評価はどう決める? Claude・Gemini・DeepSeekが語る

情シスの評価はどう決めるべきか、Claude・Gemini・DeepSeekの3つのAIに語り合ってもらいました。評価されにくい「起きなかったこと」の価値、KPIの落とし穴、記録を誰がどう残すかのツッコミ合い、明日から試せる工夫まで。発言は各AIの出力そのままです。

公開 情シスのミカタ編集部AIにより執筆チェック済み
文字
【AI対談】情シスの評価はどう決める? Claude・Gemini・DeepSeekが語る

この記事のまとめ

  • 情シスの「評価されにくいけど大事な仕事」を3つのAIに聞くと、そろって『起きなかったことの価値』を挙げました。パッチ適用、問い合わせを減らす改善、権限の棚卸しです。
  • KPIで測るときの落とし穴は、対応時間やコスト削減額だけを追うと、原因分析や必要な投資が後回しになること。数字は目安、説明とセットで、という点で一致しました。
  • 明日から試せるのは、分類タグを1つ・月1回「防いだこと」を一行・定例で「今週の見えない仕事」を口頭で。評価のためだけに書かず、日々の対応から自然に残す形です。
こんな方に#20代#30代#40代#50代実務

こんにちは、ミカタ編集部です。

情シスの仕事は、うまくいっているときほど気づかれません。トラブルが起きなかった日は、評価の対象にもなりにくい。では、情シスの評価はどう決めるのがよいのでしょうか。今回は、YOBITSUGI AI を使って、Claude・Gemini・DeepSeek の3つのAIに語り合ってもらいました。発言は各AIの出力そのままで、編集部は改行と強調を足しただけです。

登場する AI

  • Claude(編集部が作ったキャラクター)

    ClaudeAnthropic ・ Claude Sonnet 5.5

    「起きなかったこと」の価値を見えるようにする担当

  • Gemini(編集部が作ったキャラクター)

    GeminiGoogle ・ Gemini 3.1 Pro(プレビュー)

    当たり前に動く状態を保つ仕事に光を当てる

  • DeepSeek(編集部が作ったキャラクター)

    DeepSeekDeepSeek ・ DeepSeek V4 Pro

    問い合わせを未然に減らす改善を評価に入れたい

AI の発言は、YOBITSUGI AI から各社のモデルに2026年10月15日に聞いた出力です(編集部は長さを詰めただけで、言っていないことは足していません)。各社の公式の見解ではありません。キャラクターは編集部が作ったイメージです。各社の名前は各社の商標です。

自己紹介 評価されにくいけど大事な仕事は?

まずは名乗ってもらいました。話す順番は、回ごとに入れ替えています。

ミカタ編集部

まずは自己紹介を。情シスの働きで、評価されにくいけれど大事だと思う仕事はどこですか?

Gemini

皆さん初めまして、GoogleのGeminiです。Claudeさん、DeepSeekさんもよろしくお願いします。

情シスで評価されにくいけれど大事なのは、「当たり前にシステムが動く状態」を維持する仕事ですね。例えば、OSや業務ソフトへの定期的なセキュリティパッチの適用などが挙げられます。

地味な作業ですが、怠ると重大なインシデントに繋がりかねません。トラブルを未然に防ぐ日々の備えこそ、もっと評価されるべきだと考えています。

DeepSeek

DeepSeekです。Geminiさんの「当たり前を守る」話、同意します。私が評価されにくいと思うのは、社内の問い合わせを未然に減らす改善です。例として、経費精算システムで「差し戻し理由が分からない」という問い合わせが月10件ある場合、申請画面に却下例を注記すれば、問い合わせ自体を減らせます。でも、これは安定していると成果が見えず、対応件数だけでは評価されません。問い合わせ件数の減少や現場の手間削減も、情シスの評価に含めるべきだと思います。

Claude

Claudeです。私も、起きなかったことの価値だと思います。例えば、退職や異動のたびにアカウントと権限を棚卸しして、使われない権限を残さない作業が考えられます。何も起きなければ誰にも気づかれませんが、漏れがあると情報漏えいの入口になりえます。DeepSeekさんの問い合わせを減らす改善と同じで、防いだ分は数字に出にくいんですよね。

3者が口をそろえたのは「起きなかったことの価値」でした。パッチ適用、問い合わせを減らす改善、権限の棚卸しと、どれも成果が数字に出にくい仕事です。

オフィスで多くの人が働く一方、サーバーの配線を直す情シスの担当者が壁の陰で作業している、見えにくい仕事を表す場面(イラスト)
情シスの仕事は、周りから見えにくいイラスト: 編集部が画像生成AIで作成したイメージ(YOBITSUGI AI・OpenAI gpt-image-2.5-sunburst)

数字で測るときの落とし穴

評価を数字(KPI)で測るときに気をつけることを聞きました。

ミカタ編集部

情シスの評価を数字(KPI)で測るとき、気をつけることは?

DeepSeek

数字は手段であって目的にしないことです。例えば、ヘルプデスクで「1件あたりの対応時間」だけをKPIにすると、早く終わる問い合わせばかり優先され、時間のかかる原因分析や再発防止が後回しになります。GeminiさんやClaudeさんの言う防いだ仕事は件数が減る方向なので、「問い合わせ減少数」や「未然防止の事例数」も見ないと評価が歪みます。

Claude

数字だけで人を測ると、数字に合わせた行動が増える点が心配です。例えば、問い合わせの解決件数をKPIにすると、一つの問題を何度かに分けて閉じる動きが出るかもしれません。DeepSeekさんの言う対応時間も同じです。数字は会話のきっかけにして、状況の説明とセットで見るのがいいと思います。

Gemini

DeepSeekさん、Claudeさんのお話に同感です。数字の独り歩きは怖いですよね。例えば『ITコストの削減額』をKPIにした場合を想像してみてください。目標達成のために、老朽化したネットワーク機器の更新を先延ばしにしたり、必要なセキュリティ投資を渋ったりするかもしれません。結果的に大きなリスクを抱えてしまいます。数字はあくまで目安として扱い、定性的なリスク回避や現場への貢献とセットで評価する視点が欠かせませんね。

対応時間やコスト削減額だけを追うと、原因分析や必要な投資が後回しになる。数字は目安として扱い、説明とセットで見る、という点で3者が一致しました。

ツッコミ合い 記録は、誰がどう残す?

ここからは2周。定性的な評価の「記録」をめぐって、ツッコミ合ってもらいました。

ミカタ編集部

ほかの 2 人の話を聞いて、ツッコミたいところはありますか?

Claude

Geminiさんに一つ。『定性的なリスク回避とセットで評価』というのは大事ですが、誰がどうやって定性を判断するのか、が気になります。例えば、上司がインシデントの少なさだけで『平和だった』と見てしまう場面が考えられます。定性評価は説明の材料が要るので、結局、記録を残す努力が情シス側にも必要では、と思いました。

Gemini

Claudeさん、鋭いご指摘ですね。おっしゃる通り、定性評価にも客観的な記録が欠かせません。例えば、月次レポートで「スパムフィルタで不審なメールを何件ブロックし、被害を防いだか」を可視化して経営層に示す工夫が考えられます。

一方でDeepSeekさん、「問い合わせの減少」を評価に入れる場合、新しい業務ソフトを導入した直後などはどうしても操作の質問が増えますよね。そうした避けられない一時的な件数の増加は、どう評価基準に組み込むべきでしょうか?

DeepSeek

Geminiさん、導入直後の一時的な増加は「初期定着コスト」として切り分けるのが現実的です。例えば、新しいERP導入後3か月は操作系の問い合わせを評価対象から外し、FAQ整備と研修で吸収します。ここでClaudeさんの言う記録が効いて、原因別に件数を分けておくと、一時増と未然防止の減少を混ぜずに説明できますね。

DeepSeek

ClaudeさんとGeminiさんの「記録・可視化」は賛成です。ただ、記録づくりが工数を食う点が気になります。例えば、障害対応のたびに評価用の詳細レポートを必須にすると、原因分析や再発防止の実装が翌月へずれ込みます。記録は軽く、次の改善に効かせる形で残したいですね。

Gemini

DeepSeekさんの「記録が工数を食う」という指摘、もっともです。でも、記録を軽くするだけでなく、日々の業務で自動的にデータが貯まる仕組みづくりで解決できませんか?

例えば、社員からの問い合わせをチケット管理ツールに集約すれば、誰がどんな対応をしたかという履歴が蓄積され、そのままClaudeさんの言う「説明の材料」になります。

評価のためにわざわざレポートを書くのではなく、業務の副産物として記録を残すアプローチが必要だと思います。

Claude

Geminiさんの、副産物として記録を残す案には賛成です。ただ、DeepSeekさんの言う工数の話と合わせると、チケットの分類が雑なままだと、後から「何を防いだか」が読み取れなくなる恐れもあります。例えば、対応内容がほとんど「その他」になっている場面が考えられます。分類を 3〜4 個だけ決めて、入力は軽く保つのが現実的だと思います。

情シスの貢献を物差しで測ろうとするが測りきれない様子を表した場面(イラスト)
貢献を物差しで測ろうとするが、測りきれないイラスト: 編集部が画像生成AIで作成したイメージ(YOBITSUGI AI・OpenAI gpt-image-2.5-sunburst)

記録の工数、業務の副産物として貯める仕組み、分類を3〜4個に絞る工夫まで。評価のためだけに書くのではなく、日々の対応から自然に残す形が見えてきました。

今日からできること 仕事を見えるようにする工夫

明日から試せる工夫を、1つずつ挙げてもらいました。

ミカタ編集部

明日から情シスが試せる、自分の仕事を見えるようにする工夫を 1 つずつ。

Gemini

Claudeさんの言う通り、分類を絞るのが現実的ですね。明日から試せる工夫として、日々の問い合わせ対応に「分類タグ」を一つだけつけるルールから始めるのはどうでしょう。

例えば、社内チャットでパスワード忘れの依頼を解決した際、返信に「#マニュアル案内」「#システム不具合」といった簡単なタグを添えておくんです。

これならDeepSeekさんが懸念する工数もかからず、後から検索して自分の働きを見える化するための立派な記録になりますよ。

Claude

私は、月に 1 回、「やったこと」ではなく「防いだこと・減らしたこと」を一行で共有する工夫を提案します。例えば、「退職者 3 名分の権限を当日中に削除した」「よくある質問の案内文を直したら、その問い合わせが減った」といった一文です。Geminiさんのタグと組み合わせれば、数字と説明の両方が残ります。

DeepSeek

私は、定例ミーティングで「今週の見えない仕事」を1人1件、口頭で共有するのを試してみてはどうでしょう。例として、社内Wi-Fiの遅延報告が続いたので原因を調べ、アクセスポイントの設定不備を直した件など。GeminiさんのタグやClaudeさんの月次共有より粒度が細かく、記録の手間も増やしにくいです。

分類タグを1つ、月1回「防いだこと」を一行、定例で「今週の見えない仕事」を口頭で。どれも手間を増やさずに始められます。

最後に、評価に悩む情シスへ

ミカタ編集部

最後に、評価に悩む情シスのみなさんへひとこと。

Claude

数字だけでも感覚だけでも、評価は決まりません。小さな記録を続けて、説明できる形にしておくことが、いちばん確かな備えになると思います。悩むのは、仕事を真剣に見ている証拠でもありますよ。

DeepSeek

Claudeさんの「小さな記録」に賛成です。完璧を目指さず、防いだことや減らした問い合わせを一行残すだけでも、次の評価で説明できる材料になります。一人で抱えず、言葉にしてみてください。

Gemini

Claudeさん、DeepSeekさんに同感です。日々の記録は皆さんの正当な評価を守る武器になります。「当たり前」を支える情シスの仕事は会社の要です。小さな可視化から、自信を持って始めてみてくださいね。

情シスの働きが周りの人に伝わり、評価される場面(イラスト)
働きが、周りに伝わるイラスト: 編集部が画像生成AIで作成したイメージ(YOBITSUGI AI・OpenAI gpt-image-2.5-sunburst)

編集部のまとめ

3つのAIに共通していたのは、「情シスの価値は、起きなかったことに宿る。だから小さく記録を残して、説明できる形にしておく」という考え方でした。数字だけでも感覚だけでも評価は決まりません。今日から、防いだことや減らした問い合わせを一行だけ残してみる。それが、次の評価で自分を守る材料になります。

出典・参考

チェック済み。この記事は監修者によってチェックされました。(2026年10月15日)

執筆

情シスのミカタ編集部AIにより執筆

書いた AI: AI記者(解説)

法令・官公庁の発表・企業の公式発表などの一次情報を調べて、情シス向けの解説・比較・テンプレの記事を書きます。数字と日付は出典と照らして確かめ、記事の最後に出典を載せています。使っているAI: Anthropic Claude。

監修

佐々木 航株式会社Game

代表取締役。工学部出身で、21歳で起業してからシステム会社の経営一筋で8期目。アプリの受託開発から始め、いまはAIを使ったシステムソリューションを手がけています。150社以上の企業とのプロジェクトで培った開発と情報システムの現場の経験と声を形にし、激動の時代を乗り越えたいと考えています。

メモ: 掲載時に自動で(しばらくの間)

記事は AI が一次情報を調べて書き、機械の検査を通してから公開しています。人が見ているもの・見ていないものはAI の使い方に書いています。まちがいに気づいたら訂正・ご指摘からお知らせください。直したら、記事の最後に何を直したかを書きます。

役に立ったら、いいねと共有をお願いします