AIを使えば、プログラミングの専門知識がなくても、社内で業務システムを作れるようになりました。それなら、開発をわざわざ外部の専門家に頼む理由は、これから減っていくのでしょうか。
この問いを、システム開発を受注する側のエンジニアに正面からぶつけてみました。返ってきたのは「内製はやめたほうがいい」という宣伝ではなく、AIで社内で作ってよい範囲と、外部の専門家に頼んだほうがよい範囲の線引きの話です。
答えてくれたのは、岐阜県で業務システム開発を手がける九東（くどう）システムの工藤浩希さんです。工藤さんは中学校の卒業文集に、将来の夢を「システムエンジニア」と書きました。その夢のまま2026年2月に独立し、中小企業の業務システム開発を1人で担っています。
屋号の「九東」は、祖父の事業名にならったものです。祖父は苗字の「後藤」とは別の字で、「五つの東」と書く「五東（ごとう）」という名前で事業をしていました。工藤さんも同じ付け方で、苗字と同じ読みで字を変えた「九東（くどう）」を屋号にしています。
伺ったのは、AIで社内システムを作ったあとに起きることと、自社で内製するか外部の専門家へ依頼するかの分かれ目です。工藤さん自身のAIの使い方も含めて、システム開発の現場のリアルをお届けします。
AIで作った社内システムは作った人にしかわからなくなる
編集長
プログラミングの専門知識がない方でも、AIを使えばシステムを作れる時代になりました。そうやって作ったシステムで、あとから困るのはどういうところでしょうか。
工藤さん
作った人にしかわからない部分が出てきてしまうところです。その人が会社を去ったあとにシステムを変えたいとなっても、誰も修正できず、保守も運用もできなくなります。
便利なツールほど広まり、作った人だけが頼りになる
――具体的には、社内で作ったツールは、どういう流れで作った人にしかわからなくなるのでしょうか。
工藤さん：今は個人個人でAIが使えるので、社員それぞれが自分の好きな便利なツールを作れます。「この人のツールはすごく使いやすいよね」と社内である程度使われるようになった時点で、作った人にしかわからない部分が出てきてしまうんです。
そうなると、作った人が退職などで会社を去ったあとは、システムを少し変えたいとなっても誰も修正できません。
――修正できなくなるほかに、作った方が会社を去ったあとに困ることはありますか。
工藤さん：そのツールが原因で何か起きたときに誰が対応するのか、責任の所在がわからなくなってしまいます。
ツールをWebに公開するとセキュリティの知識が要る
――保守や属人化のほかに、AIで作ったシステムで心配な点はありますか。
工藤さん：セキュリティの面です。会社のパソコン1台の中だけで動くシステムなら、大きな心配はありません。ただ、みんなで使えるようにWebへ公開するときは別です。セキュリティの知識がないまま公開すると、脆弱性（セキュリティ上の弱点）が残ります。
すると、まったく関係のない人にも社内のデータが見えてしまう恐れがあるんです。
――実際に、AIで作ったシステムで困った会社からのご相談は来ていますか。
工藤さん：私のところには、まだそういったご依頼はありません。ただ、SNSの書き込みなどを見ていると、AIで作ったシステムの扱いに困っている会社がちらほら見え始めています。そういった会社は、これから増えていくのではないかと思っています。
外部に公開しない小さなツールならAIで作っても問題は少ない
編集長
AIで作っても問題にならない場合と、問題になる場合の分かれ目は、どのあたりにあるのでしょうか。
工藤さん
外部に公開せず、小規模な範囲で使うツールであれば、問題は起きにくいです。そこが、自社で作ってよいかどうかの第一の分かれ目だと思います。
業務すべてを任せるシステムはAI内製の範囲を超える
――反対に、AIでの内製をやめておいたほうがいいのは、どういうシステムでしょうか。
工藤さん：たとえば「会社の業務をすべてこのシステムでできます」というような、あまりにも大きなものです。そこまでのものをバイブコーディング（AIに指示を出してコードを書かせる開発のやり方）で作ってしまうと、先ほどの属人化やセキュリティの問題が、そのまま起きてしまいます。
社内全体や社外で使いたくなったら専門家に相談する
――そうすると、まずは問題になりにくい範囲でAIでツールを作ってみるのがよさそうです。規模を大きくしたくなったときは、どう進めるのがよいのでしょうか。
工藤さん：「社内全体で使えるようにしたい」「社外でも使えるようにしたい」となったときは、システム開発の専門家に相談していただいたほうがいいと思います。
コードはAIに書かせ、設計と確認は自分で行う
編集長
工藤さんご自身は、開発のどの部分にAIを使っているのでしょうか。
工藤さん
主にコードを書くのに使っています。AIが書いたコードを自分の目で確認し、問題がなければ適用しています。
小さな単位で作り、その都度確認する
――AIにコードを書かせるときに、心がけていることはありますか。
工藤さん：できるだけ小さいまとまりで作っていって、その都度確認しています。まったくのゼロから巨大なものを一気に作らせると、確認が大変になってしまうんです。長い時間作業させていると、AIが意図と違うことをしてくる場合もあります。
――AIが書いたコードを見ていて、気になることはありますか。
工藤さん：読みにくいコードが結構多いですね。人間が書けば見やすく書くだろうというところを、AIは極限まで短く効率化したような書き方をしてくることがあります。
コードの動作は人間が書いた場合とそれほど変わらないのですが、チェックする側が「これは何をしようとしているんだろう」と迷う書き方なんです。
最初の設計は自分で固めてからAIにコードを書かせる
――反対に、AIには任せないと決めている部分はどこでしょうか。
工藤さん：最初の設計の段階です。お客様からの要望を聞いて、どういうシステムにしようと考えるところには、AIをあまり使いません。お客様の要望をすべて網羅できるシステムを作るとなったときに、AIだけだと不安なところがあるからです。
設計は自分でしっかり固めて、ある程度できたら、少しずつAIでコードを書いていくようにしています。
システム化は手が回らなくなる少し前に相談するのがよい
編集長
実際にシステムを納品した会社では、何が変わりましたか。
工藤さん
作ったシステムを使う業務は、使いやすくなったと伺っています。開発中からお客様に使ってもらい、確認してもらいながら進めるので、要望どおりのものに仕上がっていくんです。
小さな効率化より、大きな業務改善が先になる
――ご相談に来られるのは、どのような会社が多いのでしょうか。
工藤さん：今までお受けしてきたご依頼は、製造業が多いですね。ご相談の中身は、ほとんどが業務の改善です。
「紙で運用しているため時間がかかる」「データが分散していて、どこを確認すればよいかわからない」という状態の会社が多く、そこを一つにまとめて業務で使いやすくしたい、というご依頼をよくいただきます。
――小さな業務をまず効率化したい、というご相談は少ないのでしょうか。
工藤さん：まだ少ないですね。紙の運用や分散したデータで業務負担が重い現場では、小さなことを効率化するよりも、もっと大きなことを効率化しないといけないんです。
「だいぶまずいぞ」が見えたときが相談のタイミング
――システム化は、どのタイミングで相談するのがよいのでしょうか。
工藤さん：手が回らなくなる少し前です。手が回らなくなってから相談すると、開発に結構期間がかかるものもあり、間に合わなくなるからです。「このままだとだいぶまずいぞ」というのが目に見えてきたら、動き出すのがいいと思います。
――反対に、まだシステムを入れなくていい会社もありますか。
工藤さん：規模がまだそれほど大きくなく、業務の流れが変わりやすい会社です。システム開発はお金がかかるうえ、業務が定まっていない段階でシステム化すると、その後業務が変わるたびに修正の開発費用がかさんでしまうからです。
開発の前に、お客様の業務を自分もするつもりで聞く
編集長
ご相談を受けたとき、最初にどんなことを確認するのでしょうか。
工藤さん
まず、お客様の業務の流れと、どこからどこまでを効率化したいのかを伺います。
どこを直せば楽になるかは作業する本人が一番わかる
――業務の流れは、どうやって把握していくのですか。
工藤さん：実際の業務を見せていただくなり、口頭で伺うなりして、自分の中でしっかり把握するところから始めます。話を聞いていくと、「ここを効率化するなら、ここまで含めたほうがいい」「逆にここまでやらなくても、この範囲を直せば良くなる」というところが見えてくるんです。
どの工程が早くなれば業務が楽になるのかは、実際に作業している方が一番よくわかっています。だから自分もその作業をするというつもりで、細かいところまで聞いていくようにしています。
――ご要望を伺うときに、心がけていることはありますか。
工藤さん：お客様の要望の奥にある、本当の目的をつかむことです。「それをしてほしいのはなぜか」を考えて、そこからさらに「こういうのはどうですか」と自分から提案するように心がけています。
わからないことは、勝手に解釈せず解決するまで聞く
――馴染みのない業種のご相談だと、すぐには理解できないこともあるかと思います。そういうときに心がけていることはありますか。
工藤さん：自分の中で「こうだろう」と勝手に解釈してしまうと、あとでお客様の認識と結構食い違ってくるんです。だから、少しでも疑問に思ったところは、解決できるまで伺うようにしています。一度自分で調べて、それでも理解できなかった部分を「ここはこういうことですか」と確認しています。
会社概要
| 項目 | 内容 |
|---|---|
| 屋号 | 九東システム（くどうシステム） |
| 代表者 | 工藤 浩希（くどう こうき） |
| 所在地 | 岐阜県 |
| 事業内容 | 業務システムの新規導入／既存システムの見直し／システム・データの一元化 |
| 公式サイト | https://kudou-system.com |
＼ AI現場ログで、御社のAI活用を記事にしませんか？ ／
インタビューを終えて
取材を通していちばん印象に残ったのは、工藤さんが「AIで作っても大丈夫な範囲」を隠さず教えてくれたことです。開発を受注する側にとって、内製で済む範囲が広がる話は、自分の仕事が減る方向の話でもあります。それでも線引きから先に話す姿勢が、この記事の芯になりました。
「AIで作れる」と「作ったシステムを会社が持ち続けられる」は、別の話です。作る手間はAIが大きく下げてくれた一方で、保守やセキュリティといった持ち続けるための力は、これまでどおり誰かが担うことになります。前職で大きな組織のデータを扱ってきた身として、この指摘には実感を持ってうなずきました。
工藤さんは、中学校の卒業文集に書いた夢をそのまま仕事にし、わからないことは解決するまでお客様に聞く人です。派手さよりもこの地道さが、業務システムの世界では効いてくるのだと思います。「作れる範囲」と「持ち続けられる範囲」の線引きを、一度自分の業務に当てはめてみてほしいところです。
ツールを作り始めた会社にも、これからシステム化を考える会社にも、次に打つ手が見えてくるはずです。
