既存コードの中身を説明させる｜AIツールの選び方と聞くべき質問

既存コードの中身を説明させるのAIツールは、機能表を並べても選べません。どの製品も「できます」と書いてあるからです。この記事では、実際に差が出る軸と、営業に聞くべき質問を書きます。

機能表が役に立たないのには理由があります。できるかどうかではなく、どのくらいの手間でできるかが問題だからです。「例外に対応できます」と書いてあっても、対応するのに毎回5分かかるなら、件数が多い業務では使えません。逆に、機能表では見劣りしても、例外の処理が1クリックで済む製品のほうが現場では速い。この差は、実際に触ってみないと分かりません。だからこそ、試用で何を見るかが決め手になります。

この記事でわかること

この業務で実際に差が出る軸
機能表では分からないこと
営業に聞くべき質問
候補を絞る順番

使われている道具の種類

この業務では、コード解析サービス、生成AI（開発向け）あたりが候補になります。

道具を探す前に決めること

いまのやり方のどこを置き換えるのか（全部か、一部か）
既に使っているシステムと繋ぐ必要があるか
誰が使うのか（担当者だけか、全社か）

この3つが決まっていないまま製品を見ると、機能の多さで選んでしまいます。機能が多い製品は、たいてい設定も運用も重くなります。

専用の製品でなくてよいこともある

いま使っている業務システムに、同じ機能が含まれていることがあります。上位プランに切り替えるだけで済むなら、そのほうが安く、接続の手間もありません。新しい製品を探す前に、手元のシステムでできることを確かめてください。件数が月に数十件しかないなら、標準機能で十分なことがほとんどです。

実際に差が出る軸

軸	見るところ	なぜ差が出るか
自社データでの精度	試用で実際に読ませた結果	カタログの数字はその製品が得意な条件での値
例外の扱い	うまくいかなかったときの画面	例外は必ず出る。そこの作りで運用の重さが決まる
既存システムとの接続	「連携可」の中身	連携できると、そのまま繋がるは違う
設定を誰が変えられるか	管理画面の権限設計	業者しか変えられないと、変更のたびに費用と時間がかかる
記録の残り方	誰が何をしたかのログ	問題が起きたときに追えるかどうかが分かれる
解約時のデータ	持ち出せる形式	出せないと乗り換えられず、値上げを飲むしかなくなる

いちばん効くのは「例外の扱い」

うまくいく案件は、どの製品でもうまくいきます。差が出るのは、うまくいかなかったときです。説明を鵜呑みにして、実際の挙動と違う理解のまま改修するという場面で、画面がどう見えて、担当者が何をすればよいのか。ここを試用で必ず確かめてください。

機能表では分からないこと

画面の使いやすさ。毎日触る人にとっては、機能の数より1画面の操作数が効く
問い合わせの返り。導入前は早く、導入後は遅い会社がある。既存顧客に聞くのがいちばん確か
更新の頻度。更新が止まっている製品は、法改正や仕様変更についていけない

営業に聞くべき質問

自社のデータで試させてもらえますか（断られたら候補から外す）
説明を鵜呑みにして、実際の挙動と違う理解のまま改修するという場面では、画面はどうなりますか
設定は自社で変えられますか。変えられないのはどの範囲ですか
導入をやめた会社はどんな理由でしたか
解約したときにデータはどの形式で出せますか
過去3年で価格を変えたことはありますか

答え方で分かること

「導入をやめた会社はどんな理由でしたか」に答えられない営業は、導入後の面倒も見られません。失敗例を持っている会社のほうが、自社の弱点を分かっています。

候補を絞る順番

置き換える範囲で絞る。作った人がいないコードを読み解くのに何日もかかっているの部分だけでよいなら、全部入りの製品は要らない
既存システムとの接続で絞る。繋がらない製品はここで落ちる
自社データでの精度で絞る。ここまでで2〜3社に絞れているはず
例外の扱いで決める。最後は毎日触る担当者に触ってもらって決める

ここで使うのは生成AI

文章を書く・要約する・分類する。事実の正しさは保証されないので、確かめる工程が要る。

この道具ができること・気をつける点

	内容
得意	文章を書く・要約する・分類する。
気をつける点	事実の正しさは保証されないので、確かめる工程が要る。
任せ方	出力を人が確かめる工程を挟む。確かめる人と手順を決めてから始める。

任せてよい範囲

この業務は確かめてから使うに当たります。出力を人が確かめる工程を挟む。確かめる人と手順を決めてから始める。

この線引きは、精度の高さで決めるものではありません。誤ったときに何が起きるかで決めます。精度が99%でも、誤りが支払や外部への通知につながるなら人が全件を見る必要がありますし、逆に精度が80%でも、誤りがその場で気づける形なら任せて構いません。製品を選ぶ前に、この線をどこに引くかを決めておいてください。線が決まっていないと、確認の設計ができず、運用の重さも見積もれません。

費用のかかり方

開発者1人あたりの月額。

見落とされがちな費用

費目	見落とされる理由
初期の設定費用	月額だけを比べて、導入時の設定に別費用がかかることを見落とす
社内の人件費	設定と検証に自社の担当者が何時間使うかが見積もりに入らない
既存システムとの接続	「連携できます」と「そのまま繋がります」は違う。開発費が別に要ることがある
教育の時間	使う人の数だけ、覚える時間がかかる

この4つを足すと、月額だけで比べたときの順位が入れ替わることがよくあります。特に効いてくるのが社内の人件費です。設定と検証に自社の担当者が何十時間も使うことは珍しくありませんが、見積書には一行も出てきません。製品費用が安くても、設定が難しくて社内の手間が大きい製品は、総額では高くつきます。

起きやすい失敗

この業務でいちばん多いのは、説明を鵜呑みにして、実際の挙動と違う理解のまま改修する。という失敗です。

なぜ起きるか

AIの出力は、間違っていても自信のある形で出てきます。人は、迷いのない書き方をされると確かめる気が薄れます。精度が高い道具ほど、この失敗が起きやすくなります。9割合っていると、残りの1割を探す気がなくなるからです。

防ぎ方

重要な箇所は必ず実際に動かして確かめる。説明で終わらせない。

防ぎ方を設計するときは、「全項目を同じ厚さで見る」をやめるのが要点です。全部を見ようとすると、時間が足りなくなって結局どれも薄くなります。項目ごとに精度を出し、誤ったときの影響が大きい項目だけを厚く見て、残りは抜き取りにする。この設計ができると、確認の時間が減ったうえで、いちばん危ない誤りは捕まえられます。

防ぎ方を「気をつける」で終わらせないでください。気をつけるのは仕組みではありません。誰が・いつ・何を見るかを、手順として書いてください。

効果をどう測るか

測る指標を先に決めないと、導入後に「効果があったか」を聞かれて答えられません。この業務ならコードを理解するまでの日数。

導入前に控えておく数字

上の指標を、導入前の1ヶ月ぶん記録する（比べる相手が無いと効果が出せない）
件数の波を控える（月末に集中するのか、通年で平らなのか）
いま何人が何時間かけているかを、推測ではなく実測で控える

数字は誰が記録するか

毎月記録する担当を決めてください。誰の仕事でもない状態にすると、3ヶ月で止まります。止まると、効果があったのか無かったのかを誰も言えなくなり、次に契約を見直すときの材料がありません。記録は複雑にしないでください。月に一度、数字を1行足すだけで十分です。凝った集計を作ると、作った人が異動した時点で止まります。

測るときに間違えやすいこと

導入直後に測らない。慣れるまでは前より遅くなるのが普通で、そこで打ち切ると必ず「効果なし」になる
件数だけを見ない。処理件数が増えても、確認が薄くなっていれば改善ではない
平均だけを見ない。いちばん時間がかかった案件がどうなったかを一緒に見る

社内で比較表を作る

営業から渡される比較表は、その製品が勝つように作られています。自社の軸で、自社が作ってください。

列に並べるもの

軸	重み	測り方
自社データでの精度	大	試用で実測。項目ごとに分ける
例外時の画面と手順	大	試用で、わざと失敗させて見る
既存システムとの接続	大	情報システムに確認してもらう
3年の総額	中	社内人件費を含めて計算
設定変更の自由度	中	管理画面を触らせてもらう
解約時のデータ	中	契約書で確認
問い合わせの速さ	小	試用中の返信時間を記録

点数を付けない

総合点にすると、いちばん大事な軸が薄まります。「自社データでの精度が基準を下回ったら、他がどれだけ良くても落とす」という決め方のほうが、あとで後悔しません。落とす条件を先に決めてください。

決める人を先に決める

最後に決めるのは、毎日触る担当者です。使わない人が決めると、使われない製品が入ります。情シスの担当者に必ず触ってもらってください。

自社の条件で候補が変わる

件数が少ない場合

月に数十件しかないなら、専用の製品よりいま使っているシステムの標準機能で足りることがあります。追加費用なしでできることを先に確かめてください。

件数が多い場合

従量課金だと高くつきます。月額固定か、件数の多い階層の単価を確かめてください。上限を超えたときの扱いも一緒に聞いてください。

拠点が複数ある場合

拠点ごとにやり方が違うことがあります。先に統一しないと、拠点ごとに設定が要ります。統一できないなら、拠点別の設定ができる製品を選んでください。

既存システムを使っている場合

繋がるかどうかで候補が大きく減ります。製品を探す前に、情報システムに接続の可否を聞いてください。「連携できます」と言われても、そのまま繋がるとは限りません。開発費が別に要るかを必ず確かめてください。

担当者が1人しかいない場合

設定と運用を1人で抱えると、その人が休んだときに止まります。2人目が触れる形にするか、業者が面倒を見る契約にしてください。

候補から外してよい製品

次のどれかに当たるなら、他がどれだけ良くても外して構いません。

自社のデータで試させてもらえない。カタログの精度でしか判断できない製品は、導入後に必ず揉める
年間契約でしか売らない。合わなかったときに止められない
解約時にデータを出せない。乗り換えられないと、値上げを飲むしかない
導入をやめた会社の理由を答えられない。自社の弱点を把握していない
設定を業者しか変えられない。業務が変わるたびに費用と時間がかかる
更新が1年以上止まっている。法改正や仕様変更についていけない

値段の安さで例外を作らない

上の条件に当たる製品が安くても、外してください。安さで飲んだ条件は、あとで必ず効いてきます。特に「データを出せない」は、次の乗り換えを丸ごと塞ぎます。

商談で確かめる順番

製品説明を最後まで聞いてから質問すると、時間が足りなくなります。最初に条件を伝えて、合わなければそこで終えてください。

冒頭で伝えること

対象の業務（既存コードの中身を説明させる）と、置き換えたい範囲
月間の件数と、例外の割合
使っている既存システムの名前
試用で自社データを使いたいこと
検討している期間と、決める時期

ここで合わない製品は、その場で分かります。説明を聞く時間を節約できます。

デモで見せてもらうこと

見るもの	確かめる点
普通の案件の流れ	担当者の操作が何回で済むか
例外が出たときの画面	何が起きたか分かるか。次に何をすればよいか書いてあるか
管理画面	設定を自社で変えられる範囲
記録の画面	誰が何をしたか追えるか

その場で聞く

「あとで回答します」が多い営業は、導入後も同じです。その場で答えられる範囲が、その会社の理解の深さです。

あとで乗り換えられるようにしておく

最初に選んだ製品が、3年後も最適とは限りません。乗り換えられる形で契約しておくことが、値上げへの唯一の備えです。

契約時に確かめること

データをどの形式で出せるか（CSVなど、他で読める形か）
データを出すのに費用がかかるか
設定の内容を持ち出せるか
解約の申し出はいつまでか

自社に残しておくもの

設定の内容を、製品の外に文書として残す
運用の手順を、製品名に依存しない書き方で残す
月ごとの指標を、自社の表に控える

これらが製品の中にしか無いと、乗り換えたときに全部作り直しになります。作り直しの手間が大きいと分かっていると、値上げを飲むしかなくなります。

複数の製品を併用する場合

情シスで複数の製品を使うと、それぞれの記録がばらばらになります。指標だけは自社の1つの表にまとめてください。製品ごとの画面で見ていると、全体が見えなくなります。

要件をどう書くか

要件を書かずに製品を見ると、見た製品の機能が要件になってしまいます。先に書いてください。

書くこと

項目	書き方の例
対象の業務	既存コードの中身を説明させるのうち、◯◯の部分
月間の件数	実測値。繁忙期の最大も書く
例外の割合	実測値。どんな案件が例外かも書く
接続先	既存システムの名前と版
必須の条件	満たさなければ落とす条件を3つ以内で
あるとよい条件	無くても採用できる条件

必須の条件は3つ以内にする

必須を10個並べると、どれも満たす製品が無くなります。本当に無いと困るものだけを必須にしてください。残りは「あるとよい」に落とします。

要件を営業に渡す

この1枚を先に渡すと、合わない製品はその場で分かります。お互いの時間が節約できます。渡しても提案が的外れなら、その会社の理解が浅いということです。

要件は途中で変えてよい

試用で分かることがあります。変えたときは、なぜ変えたかを書き足してください。書いておかないと、あとで「なぜこの製品を選んだのか」が説明できなくなります。

試用の結果をどう読むか

数字が出ても、読み方を間違えると選択を誤ります。

精度は項目ごとに見る

全体の精度でなく、項目ごとに出してください。精度の高い項目は確認を外し、低い項目だけ人が見るという設計ができれば、運用が軽くなります。まとめた数字では、この設計ができません。

確認の時間を測る

精度が高くても、確認の画面が使いにくければ時間はかかります。1件あたりの確認時間を実測してください。コードを理解するまでの日数に対して、この時間が効いてきます。

慣れの影響を分ける

試用の初日と最終日で、同じ人が同じ作業をどれだけ速くできたかを比べてください。差が大きければ、それは製品の問題ではなく慣れの問題です。導入直後の遅さで判断しないための材料になります。

例外の傾向を見る

例外の傾向	意味
特定の書式で必ず出る	設定で対応できる可能性が高い
ばらばらに出る	対象範囲が広すぎる。狭める
特定の取引先で出る	その取引先ぶんだけ手作業にする判断もある

担当者の感想を必ず聞く

数字が良くても、毎日触る人が使いにくいと言うなら、その製品は定着しません。感想は数字と同じ重さで扱ってください。

最後にどう決めるか

候補が2〜3社に絞れたあと、決め方で迷うことがあります。総合点を付けたくなりますが、それはやめてください。

落とす条件を先に決める

総合点にすると、いちばん大事な軸が他の軸で薄まります。代わりに、「これを満たさなければ、他がどれだけ良くても落とす」という条件を3つ以内で決めてください。既存コードの中身を説明させるなら、自社データでの精度が基準を下回る、既存システムと繋がらない、解約時にデータを出せない、あたりが候補です。この3つで落ちなかったものだけを、次の段階で比べます。

例外の扱いで差が付く

うまくいく案件は、どの製品でもうまくいきます。差が出るのは、うまくいかなかったときです。説明を鵜呑みにして、実際の挙動と違う理解のまま改修するという場面で、画面に何が表示されるか。担当者が次に何をすればよいか書いてあるか。手で直した結果が次に活きるか。ここを試用で必ず確かめてください。毎日触る人にとっては、この部分の作りが1日の負担を決めます。

毎日触る人に決めてもらう

最後は、情シスの担当者に決めてもらってください。使わない人が決めた製品は、使われません。決裁する人は費用と条件を見ますが、どちらの製品でも条件が満たされているなら、使う人の意見を優先してください。ここで押し切ると、導入後に「上が勝手に決めた」という空気が残り、定着しなくなります。

決めた理由を書き残す

なぜその製品にしたのかを1枚に書いてください。特に、安いほうを選ばなかったならその理由を書いてください。半年後に「なぜこれにしたのか」と聞かれたとき、記録が無いと説明できません。担当者が変わったときにも、この1枚があるかどうかで引き継ぎの質が変わります。

決めなかった製品も残す

落とした製品と、その理由も残してください。次に見直すときに、同じ製品をもう一度調べる手間が省けます。落とした理由が解消されている可能性もあるので、「いつ・何を理由に落としたか」まで書いておいてください。

選び終わったあとに残しておくもの

比べた結果は、選んだ製品の情報より価値があります。落とした製品と、落とした理由と、落とした日付を残してください。次に見直すときに、同じ製品をもう一度調べる手間が省けます。落とした理由が解消されている可能性もあるので、日付が重要です。1年前に「接続できない」で落とした製品が、いまは接続できるようになっていることは普通にあります。

比べた軸そのものも残す

どの軸で比べたかを残しておくと、次の製品選びがそのまま速くなります。情シスで別の業務にAIを入れるときも、同じ軸が使えます。自社データでの精度、例外時の画面、既存システムとの接続、解約時のデータ。この4つは業務が変わっても効きます。一度作った比較の型は、社内の資産として使い回してください。

同じ開発・情報システムの業務

開発・情報システムでは、次のような業務でもAIが使われています。まとめて考えると、道具を共通にできることがあります。

業務ごとに別々の製品を入れると、契約も管理も記録もばらばらになります。同じ部門の中で似た技術を使う業務があるなら、まとめて1つの製品でまかなえないかを先に確かめてください。まとめられれば、費用が下がるだけでなく、覚えることも1つで済みます。逆に、無理にまとめようとして、どの業務にも中途半端な製品を選んでしまうこともあります。判断の基準は「置き換えたい部分の作業が同じ形かどうか」です。形が違うなら、別々に選んだほうが結果的に安くつきます。

業務	使う技術	任せ方
<a href=”/gyomu-84-dounyu/”>コードの下書きを書かせる</a>	生成AI	確かめてから使う
<a href=”/gyomu-85-dounyu/”>テストケースを作る</a>	生成AI	確かめてから使う
<a href=”/gyomu-86-dounyu/”>障害の原因を絞り込む</a>	生成AI	人が判断する
<a href=”/gyomu-87-dounyu/”>社内ヘルプデスクの一次対応をする</a>	生成AI	任せてよい範囲が広い
<a href=”/gyomu-88-dounyu/”>仕様書からコードの雛形を作る</a>	生成AI	確かめてから使う
<a href=”/gyomu-90-dounyu/”>脆弱性を見つける</a>	AI検出	確かめてから使う

開発・情報システムの一覧を見る

よくある質問

そもそも自社の規模でも効果が出ますか

会社の大きさではなく件数で決まります。コードを理解するまでの日数を1ヶ月ぶん数えてみてください。月に数件しかないなら、設定と確認の手間のほうが大きくなるので、人がやったほうが速いことが多いです。逆に、担当者が毎日触っている業務なら、会社の規模に関係なく効きます。判断の目安は「担当者がこの作業に週5時間以上使っているか」です。それを下回るなら、いまは見送って、件数が増えたときにもう一度考えてください。

担当者の仕事がなくなりませんか

この業務でAIが置き換えるのは、作った人がいないコードを読み解くのに何日もかかっているという部分です。判断と例外処理は残りますし、出力を確かめる作業が新しく増えます。実際には、手を動かす時間が減って、確認と改善に回る時間が増えるという形になります。ただし、この説明を先にしておかないと、現場は身構えます。導入を伝えるときは、機能ではなく「あなたの1日がどう変わるか」から話してください。

失敗したときに元に戻せますか

戻せる形で始めてください。既存のやり方を止めずに並行で動かし、指標が改善してから切り替えます。いきなり切り替えると、戻す判断そのものができなくなります。並行で動かす期間は手間が二重になりますが、その期間があるからこそ、精度も確認の時間も実測できます。「3ヶ月試して合わなければ止める」と先に宣言しておくと、現場の抵抗も小さくなります。

どのくらいの期間で効果が出ますか

慣れるまでに1〜2ヶ月、効果が数字に出るまでにさらに1ヶ月ほどを見てください。最初の数週間は、前のやり方より遅くなるのが普通です。手が覚えていた作業を、毎回考えながらやることになるからです。3ヶ月未満で判断すると、この学習期間をそのまま「効果なし」と読み違えます。判断の時期を導入前に決めて、それまでは途中経過で騒がないと決めておいてください。

社内の反対をどう説得すればよいですか

説得より先に、数字を出してください。いまこの業務に月何時間かかっているかを実測し、3社の見積もりを並べ、3年の総額を出す。この3つがそろっていれば、反対の理由が「なんとなく不安」から具体的な論点に変わります。そのうえで、「一部門で3ヶ月試して、数字が出なければ止める」という形にしてください。取り返しがつくと分かれば、反対は大きく減ります。

どの部署が主導すべきですか

情シスが主導するのが基本です。業務を分かっている人でないと、置き換える範囲を決められないからです。情報システムは接続と権限を、経理は費用の妥当性を見る役割で入ってもらってください。情報システムが主導すると、業務の実態と合わない範囲が選ばれやすくなります。逆に業務部門だけで進めると、接続とセキュリティで後戻りします。

大手の製品を選べば安全ですか

大手は倒れにくいですが、自社の業務に合うかは別です。小さい会社のほうが融通が利くこともあります。規模ではなく、上の軸で比べてください。

海外製と国内製はどちらがよいですか

生成AIを日本語で使うなら、日本語での精度を必ず試用で確かめてください。国内製でも日本語が弱いことはありますし、その逆もあります。

まとめ

機能表ではなく、例外の扱いで差が出る
自社データで試せない製品は候補から外す
「導入をやめた会社の理由」を聞く
最後は毎日触る担当者が決める