Google Workspace割引クーポン無料配布中! 詳しくはこちら

【賛否両論】AIで作ったアプリを会社で使うのは本当にアリ?現場目線で考えてみた

  • URLをコピーしました!

ごすけです。

最近、YouTubeを見ているとこんな動画ばかり目につきませんか?

「ChatGPTで社内アプリを自作してみた!」

「ClaudeやCodexを使えば誰でもシステムが作れる時代!」

確かにすごいんですよね。

プログラミングを勉強しなくても、話しかけるだけでアプリができてしまう。

見ていて「自分もやってみようかな」と思う気持ちはよくわかります。

でも私、正直言うとこれ組織で使う分には慎重派なんです。

ですが絶対に反対!!というわけでもなくて、「賛成派の言い分もわかる。じゃあどこで線を引くべきか?」というところまで考えてみました。

同じように悩んでいる方の参考になれば嬉しいです。


タップできる目次
スポンサー

私が反対派な理由:「辞めたら誰がメンテするの?」問題

まず私の立場をはっきりさせておくと、kintoneやGoogle WorkspaceのスプレッドシートをベースとしてWebアプリシステムは大賛成です。

実際にクライアントへの導入も何件もやってきました。

問題はそこじゃなくて、GitHubにホスティングして、SQLを組んで、独自サーバーで動かす系の自作アプリの話なんです。

実際こんな話、聞いたことありませんか?

【※エピソードをここに追記予定】 例:「〇〇さんが退職したら、誰もそのアプリの仕組みがわからなくなった」「どこにデータが保存されているかすら不明」など

これが「AIで自作アプリ」の一番怖いところだと私は思っています。

具体的に言うと、こういうリスクがあります。

  • 作った人が辞めた後、誰もコードを読めない
  • データがどこに保存されているか不明(ローカル?クラウド?どのアカウント?)
  • 障害が起きたとき、誰も直せない
  • セキュリティの穴があっても気づけない

少人数で、自分がずっとその会社にいるなら話は別です。でも組織として動かすシステムとなると、これは結構シビアな問題だと感じています。

イメージ写真

賛成派の言い分も、実はわかる

とはいえ、賛成派の主張を聞いてみると「なるほど」と思う部分もあるんですよね。

ちゃんと整理してみます。

属人化はkintoneやスプシでも同じでは?

これは正直、一理あります。

kintoneのカスタマイズJSが複雑化したり、AppSheetの数式が膨大になったりすると、作った人以外は触れない、なんてことはあります。

「AIで作ったから属人化する」というよりも、設計とドキュメントの問題という側面はたしかにある。

「スピードとコストが全然違う

kintoneのライセンス費用、AppSheetの開発費、毎月の維持コスト。

これと比べると「AIで1日で作った社内ツール」はコスパが圧倒的に高いケースもあります。

小規模なツールなら、費用対効果の計算は見直す必要があるかもしれない。

GitHubで管理すれば引き継げる

コードをGitHubで管理して、READMEにちゃんと概要を書いて、VercelやRailwayでホスティングする。

これができていれば「誰かが触れる状態」は作れると言う人もいます。

むしろこれを機に、コードを読める人材を育てるきっかけにもなる、という考え方もあるのでは思いますね。

イメージ

現実的な落とし所はどこか

ここが本題です。

「反対!」で終わるより、「こう使えばアリ」という基準を持っておくほうが現場では使えると思っています。

私が考える「AIアプリ自作がアリな条件」はこの3つです。

① データの置き場所が明確なこと

GoogleスプレッドシートやNotionをデータベースにする、kintoneのAPIと連携させる、など**「データが自分たちの管理下にある」**状態が大前提です。 謎のローカルDBや、作った人のアカウントだけに紐づいたクラウドはNGです。

② 「必要なときに理解できる構造」になっていること

「コードが読める人を育てよう」という話ではありません。そこはAIが解決してくれます。

私自身、もともとGASやVBAは自分で書いていましたが、生成AIが使えるようになってから自分では一行もコードを書いていません

コードをまるごとAIに渡して「全部解説して」と頼めば、理解できるんです。

修正したいときも「こう変えたいんですが」と伝えればいい。

大事なのは「コードを自分で書けるか」ではなく、「必要なときに誰かが(AIを使ってでも)理解・修正できる状態になっているか」です。

そのためには、コードがどこにあるか・何をしているかが把握できる構造になっていることが最低条件です。

③ 「壊れても困らない用途」から始めること

いきなり基幹業務に使うのではなく、「壊れても手作業に戻れる」補助ツールから始めること。

日報の集計、社内アンケートの自動集計、簡単な進捗確認ツールなど。

これなら最悪使えなくなっても業務は止まりません。

イメージ

まとめ:「作れる時代」だからこそ、設計の話をしよう

AIを使えば、プログラミング未経験でもアプリが作れる時代になりました。

これ自体はすごいことだし、否定するつもりはありません。

現に私も現在の職場で生成AIを使ってkintoneにJavascriptを設定して使いやすくしてきました。

現場からも良くなったと高評価です。

ただ、「作れる」と「組織で運用できる」は別の話です。

ツールがどんなに賢くなっても、「そのシステムが組織の管理下にあるか」という問いへの答えは、人間が用意しないといけない。

データがどこにあるか、誰がアクセスできるか、何かあったときに誰が対応するか。

コードの理解はAIに頼れる時代になりましたが、管理責任の所在だけはAIが解決してくれません。

私も勉強のために生成AIでアプリ作っていますが、現時点ではkintoneやGoogle Workspaceのような「管理主体が明確なプラットフォーム」をベースにしたシステム構築を推していくつもりです。

その上で、AIをうまく組み合わせるのがベストだと考えています。

(正直この概念も生成AIの進化スピードが早いのでどんどん変わっていきそうですけどね…)

「AIで作れる!」の熱狂の中で、ちょっと立ち止まって全体設計の話ができる人が増えると、現場はもっとうまくいくんじゃないかな、と思います。

そこは大事にしてほしいなと思う今日このごろです。

以上、ごすけでした。

ごすけ|生産技術者

1989年生まれの30代。妻と娘の3人家族。
大手メーカーからスタートアップ企業に転職。工程設計の仕事の傍ら、Google Workspaceを使って社内DXを推進中。
Google Workspaceの使い方・DX活用事例をブログで発信しています。

この記事が気に入ったら
フォローしてね!

よかったらシェアしてね!
  • URLをコピーしました!
タップできる目次