こんにちは。DeNA IT本部 IT戦略部 エンプロイーエクスペリエンスグループの根本です。

私たちのグループは、DeNAグループで使うPCの手配から資産管理までを担当しています。申請を受け取って、端末を用意して、全社の資産台帳に登録して、利用者に渡す。この一連を毎日回しているチームです。申請数は年間でおよそ2,000件です。

そして、この流れのあちこちに長いあいだ人の手が残っていました。「そのうち直したいね」と言い続けて何年か経ってしまった、というのが正直なところです。

今回その改善に着手したのですが、そのときにAIを相談相手として使ってみました。コードを書かせるためではありません。頭のなかにしかない現状を整理したり、自分たちの設計にわざとツッコミを入れてもらったり、開発チームに渡す仕様をまとめたり。そういう使い方です。

使ったAIは工程によって違うのですが、これは戦略的に選び分けたというより、単に工程ごとに必要なものが違っただけでした。前半はチャットだけで足ります。ホワイトボードの写真を見せて意見をもらう、設計に批判を入れてもらう。外のシステムにつながっている必要はありません。

ところが後半はそうはいきませんでした。本番のフィールド構成を読む、開発側に依頼するためのチケットを起票する。このあたりは、AIが外のシステムに手を伸ばせないとどうにもなりません。

結果として、こんな分かれ方になりました。

• 現状の洗い出しは、業務内容を聞き取って、業務フロー図を作ってくれる社内ツール
• 設計とレビューは Gemini
• 実物に触れるところは Claude Code

本記事では、その具体的な試行錯誤と進め方をご紹介します。

課題：PC手配のどこに人の手が残っていたか

社内でPCを1台用意するには、申請を受け、在庫を確認し、なければ発注して納品を待ち、キッティング（初期設定やアプリのセットアップ）をして、全社の資産台帳に登録します。最後に、申請した本人が結果を見られるよう元の申請に資産番号とコメントを書き込み、ステータスを進めます。書き出してみると、それだけで結構な工程数です。

申請の入口は1つではありません。用途ごとに別の申請があり、それぞれ別の時期に作られました。

• 標準機の交換・追加：故障や老朽化など
• 特殊な構成の端末：標準機では要件を満たせない方向け
• 入社にともなう準備：入社日に合わせて端末を用意

用途が違うので、項目名も選択肢の文言も揃っていません。

この流れには、2つのシステムと1つのファイルが関わります。

• kintone：申請を受ける。サイボウズ社の業務アプリ作成ツール
• 表計算ファイル：リース会社と発注をやりとりする
• ServiceNow：全社の資産台帳。IT資産やサービス運用を管理するクラウドサービス

困っていたことを整理すると、だいたい次のようなところでした。

• 情報が分断している：この3つがつながっておらず、全体を見られる場所がない
• 属人化している：「このパターンはAさんに聞かないと分からない」という条件分岐が、担当者の頭のなかにしかない
• 転記が多い：利用者が入力した配送先の住所を手で写す作業があり、写し間違いが誤配送につながる

現状分析：担当者の頭のなかを図にする

改善の第一歩は現状を正確に知ることなのですが、着手してみるとここがいちばん難しいところでした。フローが担当者の頭のなかにあるので、聞き出さないかぎり図になりません。

ここで使ったのが、冒頭で触れた社内ツールです。チャットボットの質問に答えていくと、バックグラウンドで業務フロー図が自動生成されます。

効いたのは「聞かれるから答える」という形式でした。自分から書き出そうとすると、当たり前すぎる手順は無意識に飛ばしてしまいます。でも質問されるとちゃんと出てくるものです。

出てきた図を見て承認が二段あること、受け取り方によって手順が枝分かれすること、同じ情報を何か所にも書き写していることをあらためて理解しました。

ToBe設計：ホワイトボードの写真をAIに見せる

現状が見えたので、次はあるべき姿です。

やったことは単純で、ホワイトボードに手書きで理想の形を描いて、その写真を Gemini に渡して意見をもらう、というだけでした。

これが想像以上にうまくいきました。描いたのは、申請と台帳を直接つながずにあいだにアプリを1枚挟む形です。写真を渡しただけなのに、AIはその構造を読んで何をするフローなのかを言葉にして返してきます。

「入社」と「交換」という異なるトリガー（入り口）を、APIを通じて中央のアプリに集約している構造が素晴らしいです。データの入口は分かれていても、管理台帳は一つになっているため、情報の散逸を防げます。

助かったのは、人に説明するときに必要な「これはこういう意味でして」という前置きが要らないことでした。描いて見せて、返ってきた言葉を読んで図を直して、直した図をまた見せる。この往復を何度か繰り返しているうちに、要件が固まっていきました。

最終的には、申請と台帳のあいだに「中継用のアプリ」を1枚置く形に落ち着きました。kintone で作ったもので、手配がいまどの段階にあるのかをステータスとして持たせています。以降はこの呼び方で書きます。

設計レビュー：AIにわざと厳しくダメ出しさせてみる

設計がひととおりできたところで、今度はあえてAIに批判的な立場を取ってもらうことにしました。「このプランの運用上のリスクを、厳しく指摘してください」とお願いしたわけです。

返ってきた第一声がこれでした。

運用担当者の体がもちません

具体的な指摘は2つありました。

1つめ。表計算ファイルでの連携は危険。

リース会社との共有に表計算ファイルを使うのは危険です。1行ズレただけで全データが破損し、システムが停止します

2つめ。督促する人がいない。

ユーザーが住所を入力しなかった場合、誰が督促するのですか。担当者が毎日チェックするなら、自動化の意味がありません

どちらも、正直なところ自分たちでは「まあ何とかなるでしょう」で流していたポイントでした。

指摘を受けて、設計を3か所変えました。

ただ、正直に書いておくと、この3つはいずれもまだ動いていません。

そして1つめについては、実装を詰める段階になって、そもそも実現できないことが分かりました。社外であるリース会社は、私たちの kintone に入れないからです。考えてみれば当たり前の話なのですが、指摘の鋭さに乗せられて、一度は「たしかにそうだ」と設計を書き換えてしまっていました。AIはシステムの構造は読めても、どの会社がどのシステムにアクセスできるのかまでは知りません。

というわけで、表計算ファイルでのやりとりは今日も残っています。

設計から実装へ、AIを持ち替える

ここまでは Gemini でやっていましたが、実装の段階に入ったところで Claude Code に持ち替えました。ブラウザで使うチャットとは違って、手元の環境や外部のシステムにつないで動かせるAIツールです。

持ち替えた理由は、扱う対象が「考え」から「実物」に変わったからでした。フィールドを1つ足すかどうかという話は、既存のアプリがいまどうなっているかを見ないと決められません。

ここで助かったのが kintone の MCP でした。MCP（Model Context Protocol）は、AIを外部のシステムにつなぐための共通の仕組みです。今回は本番のアプリを、読み取り専用でつないでいます。

これを通すと、AIが本番のフィールド構成をそのまま読んでくれます。それまでは「このアプリにはこういう項目があって、型はこうで」と人間が説明していたのですが、その説明が要らなくなりました。「このアプリのフィールド構成を見て、入社の申請から転記するのに足りない項目を挙げて」と頼めば、実物を見たうえでの答えが返ってきます。

フィールド名や型を書き出して渡す手間が丸ごと消えました。この取り組みでいちばんありがたかった変化かもしれません。

開発チームへの受け渡しも、AIを通した

自動処理の実装は、同じグループ内で開発を担当しているチームにお願いしました。私たちは現状の整理から設計までを担い、そこから先は開発チームが引き取る体制になっています。ここでもAIを挟んでいます。

情シスが書く依頼は、どうしても業務の言葉になりがちです。「このステータスになったら台帳に登録してほしい」。これだけでは開発側は動けません。どのアプリのどの項目を、どういう条件で、失敗したらどうするのか。分かってはいるのですが、自分の頭のなかでは自明なので書くときに抜けます。

ここで助かったのは、開発チームが用意してくれた仕組みでした。依頼内容を聞き取ってチケットの形に変換する「スキル」を、開発チーム側が作って配布してくれています。これは Claude Code のスキルという機能で、あらかじめ聞き取る項目や守らせたいルールを定義しておくと、スラッシュコマンドで呼び出せます。私たちはそれを呼び出すだけです。

中身を少し紹介すると、こんなルールが書き込まれています。

• 依頼者は非エンジニアである前提で質問する：専門用語を使うときは必ず説明を添える
• 曖昧な回答を通さない：回答がぼやけていたら追加で質問し、答えを言い換えて復唱する
• 社内の略称や通称をそのまま書かせない：依頼者しか分からない呼び方は正式名称に直させる
• 外部システムの実際の項目名は、依頼側が確定する：「実装しながら調べてください」という丸投げを禁じている
• 1つのチケットには1つの機能まで：複数の処理をまとめて書かない

やりたいことを業務の言葉で話すと、AIが質問を重ねながら技術仕様に落とし込んでチケットとして起票してくれます。起票したあとの開発チームとのやりとりも、同じ仕組みを通しました。

このときAIが見ているのは kintone だけではありません。開発チームのソースコードが置いてある GitHub と、これまで仕様や運用をためてきた Confluence にも、同じように MCP でつないであります。どちらも読んだうえでチケットを書いてくれるので、過去の経緯を人が思い出して書き写さなくてよくなりました。地味ですが大きい変化でした。

良かったのは書き漏らしが減ったことです。「異常時はどうするか」「すでに同じレコードがあったらどうするか」を毎回聞かれるので、詰めきれていないところが起票の前に露出します。開発チームに聞かれる前に自分で気づけるので、往復が減ります。

このスキルは運用しながら開発チームが更新してくれており、このあたりは完全に乗っかっているだけなのですが、ありがたく使わせてもらっています。

切り替えの段取りも、AIと詰めた

実装の目処が立ってから、もうひとつAIに手伝ってもらったことがあります。切り替えの段取りです。

自動化で怖いのは、実装よりも切り替えのほうでした。手作業をやめるのがいつで、案内を書き換えるのがいつで、古いフォームを閉じるのがいつなのか。ここがずれてしまうとまだ動いていない手順を案内することになったり、逆に誰にも連絡が届かなくなったりします。

そこで、やることを全部書き出して事前・直前・当日・開始後の4つに並べ替えてもらいました。事前にできること、直前にやること、当日まとめてやること、始まったあとしばらく続けること。これはそのまま切り替え当日の作業リストとして使っています。

現状と今後：いま、どこまで動いているか

先ほど書いたとおり、PCの申請には3種類あります。このうち自動で流れるようになったのは、標準機の交換・追加の1つだけです。

この申請については、利用者が申請を出すと、中継用のアプリにデータが移り、そこから全社の資産台帳への登録までが人の手を介さずに進みます。

残る2つ、特殊な構成の端末と入社にともなう準備はこれまでどおり手作業です。リース会社とのやりとりも表計算ファイルのまま残っています。

残る2つの申請をつなぐこと、リース会社とのやりとりを表計算ファイルから外すこと。このあたりが次にやることです。

まとめ

振り返ってみて今回いちばんよかったのは、AIをコードを書かせる相手ではなく、相談相手として扱ったことだったと思っています。

• 答えを聞くのではなく、壁打ちする：思考の過程を共有するほど、返ってくるものが具体的になる
• 批判させる：「リスクを厳しく指摘して」と頼むだけで、自分たちが流していたところが出てくる
• チャットで足りる工程と、つながっていないとできない工程がある：後半はAIの賢さより、必要なシステムに手が届くかで決まる
• レビューの鋭さと、実行できるかは別：指摘が的確でも、その修正案がそのまま使えるとはかぎらない

手作業として残っているところは、まだいくつもあります。今後も1つずつ改善を進めながら、AIとの進め方も探していきます。本記事が同様の課題を抱える方の参考になれば幸いです。