中小企業のDX

分からなくても、まずやってみる――AIを使うようになって変わったこと

コードを書けなくても、音声入力とAIを使って試行錯誤を続け、土木設計の自動化や会社サイトの更新まで進められるようになった体験を振り返ります。

公開日
  • #AI活用
  • #音声入力
  • #OpenTypeless
  • #業務改善
  • #学び方

コードを書けなくても、AIと一緒なら必要なものを形にできるようになった

私は今でも、Pythonのコードをゼロから自力で書くことはできません。

Pythonだけではありません。HTMLも、GASも分かりません。

AIが作ったコードの一部分を見せられて、「ここだけ直してください」と言われても、自分では修正できないと思います。

それでも今は、AIを使いながらPythonの小さなツールを作り、DXFを処理し、CADやCIMの自動化を試し、WebアプリのMVPを試作するところまで経験しました。さらに、会社のWebサイトを作り、こうして技術ノートを追加しながら、自分で更新を続けられるところまで来ました。

では、そのために何を勉強したのか。

振り返ると、体系的にプログラミングを勉強したわけではありません。学生時代に情報処理へ触れたことはありましたが、その後は河川を中心とした土木設計の仕事に進みました。プログラムを作ることを仕事にしてきたわけでもありません。

今でも、自分をプログラマーだとは思っていません。

ただ、AIを使うようになってから、以前なら専門外だと思って最初から手を出さなかったことを、かなり気軽に試すようになりました。

コードを書けるようになったわけではありません。分からないままでもAIとやり取りを続け、必要なものを形にできるようになりました。

YouTubeを2倍速で見て、毎日ニュースを追った

体系的な勉強はしていませんが、何もしてこなかったわけではありません。

AI関連のYouTubeは2倍速で次々に見ました。夜にはニュースサイトで新しい動きを追い、翌朝にはAIへニュースをまとめさせ、それを読むことを続けました。

分からない言葉が出れば、そのままAIへ聞く。気になるサービスや機能があれば、実際に触ってみる。

YouTubeを2倍速で見る

夜にAI関連のニュースを追う

翌朝、AIにニュースを整理させて読む

気になったものを実際に試す

分からなければ、その場でAIに聞く

この繰り返しでした。

最初は意味が分からなかったAI、API、認証、Python、CAD自動化といった言葉も、毎日見て、聞いて、試すうちに少しずつつながるようになりました。

今でもまだまだ未熟です。それでも、自分が試したことや考えたことを、こうして技術ノートとして書けるところまでは来ました。

最初は一言目が出なかった。今は音声入力なしでは効率が悪く感じる

今では、文章をキーボードで入力するより、マイクを使ってAIと話す方が圧倒的に速いと感じています。

しかし、最初からうまく話せたわけではありません。

どの順番で話せばよいのか。どう説明すればよいのか。頭の中で文章を完成させようとして、最初の一言がなかなか出ませんでした。

そのうち、「まとまっていなくても、とりあえず話せばいい」と思うようになりました。

「いや、今の説明は少し違う」

「前提から話すと」

「うまく言えないけれど、こんな感じ」

そんな状態でも、AIとの会話は続けられます。途中の言葉からAIが意図を整理し、「そう、それが言いたかった」と思える形で返してくれることもあります。

最近は、AIの画面に付いているマイクによる音声入力もかなり高性能になりました。ただ、話し始めるたびにマウスでマイクを押し、終わったらもう一度押すという操作は、使い続けると意外に面倒です。

そこで、音声入力ソフトのOpenTypelessへAPIを接続し、パソコン上のさまざまな入力欄で音声を使うようになりました。開始と終了はキーボードで操作できるため、考えている途中でマウスへ手を移す必要がありません。

マイクへ向かって思いつくまま話すと、音声が文字になり、ある程度読みやすい形へ整えられて入力されます。AIへの指示だけでなく、文章の下書きや考えの整理にも使えるようになりました。

キーボードだけで入力していた頃は、文章を整えようとする間に、次に考えていたことが抜けてしまうこともありました。音声なら、思考が続いているうちに、そのまま言葉として外へ出せます。

頭に浮かんだことをマイクへ話す

キーボードで音声入力を開始・終了する

OpenTypelessが文字へ変換する

AIへ大量の前提や考えを渡す

返ってきた内容を見ながら、さらに話す

今では、この音声入力がない状態でAIとやり取りすると、かえって効率が悪いと感じるほどです。

音声入力で大きく変わったのは、入力速度だけではありません。AIへ渡せる思考の量と、対話を続ける速さが大きく増えました。

分からなくなったら、とりあえずスクリーンショットを送る

新しいアプリやWebサービスを触ると、知らない画面が次々に出てきます。

英語の設定画面。エラーメッセージ。認証。API。権限。聞いたことのない用語。

以前なら、その時点で一度止まっていたと思います。

今は、よく分からなければ画面をスクリーンショットし、そのままAIへ見せます。

「今この画面です。次は何をすればよいですか」

AIの説明どおりの場所にボタンがなければ、「そのボタンがありません」と新しい画面を見せます。すると、現在の画面を前提に別の経路を考えてくれます。

分からない画面が出る

スクリーンショットをAIへ見せる

一つだけ試す

結果を返す

次の手順を考える

毎回、最初から正しい答えが出るわけではありません。

それでも、分からない状態のまま、一緒に進めるようになりました。

アプリを作ること自体が勉強になった

以前、AIを使ってどこまでできるのかを知るために、小さなWebアプリを試作しました。

認証、ログイン、ユーザー管理、権限、決済。これまでほとんど触れてこなかった仕組みを、AIとのやり取りでどこまで扱えるのか試してみたかったのです。

もちろん、本番サービスとして公開したわけではありません。試作環境で動かし、MVPと呼べる形まで作ったという段階です。

エラーが出る。設定画面が分からない。説明どおりに動かない。そのたびにAIへ聞き、画面を見せ、また試しました。

繰り返しているうちに、「認証とはこういう仕組みなのか」「ログインと決済は別のものなのか」「ここでユーザーを識別しているのか」と、少しずつ意味がつながってきました。

アプリを作るために勉強してから始めたのではありません。

作ってみること自体が、勉強になりました。

作ってみたから、仕事の進め方まで学んだ

この試作で学んだのは、コードや認証だけではありません。

AIへ一度に多くのことを頼むと、どこで問題が起きたのか分からなくなる。UI、認証、ルーティング、決済など、違う役割を混ぜると原因を追いにくくなる。

だから、作業を小さく区切るようになりました。

1作業=1報告=1判断

一つ作業したら結果を確認する。エラーが出たら、そこで止まる。次へ進むか、戻るかを判断する。

最初からシステム設計を勉強して、この方法を選んだわけではありません。作って、壊して、原因が分からなくなったから、自然にそうなっただけです。

しかし今振り返ると、この考え方はアプリだけでなく、AIと一緒に仕事を進めるときにも使えるものになっています。

チャットの文脈が切れるから「母艦」を作った

当時は、今のようなプロジェクト機能を使わず、通常のチャットだけで作業していました。必要な情報は自分でコピーし、別の場所へ残していました。

会話が長くなると前提が流れる。別のチャットへ移ると文脈が切れる。「前に何を決めたのか」が分からなくなる。

そこで、重要な前提や判断を一つの場所へまとめ、必要なときに戻れるようにしました。自分の中では、その場所を「母艦」と呼んでいました。

AIとの会話を残すための「母艦」

重要な判断や経緯を残す考え方

人間同士の会話にも同じ問題があると気付く

音声ナレッジとKnowledge OSへつながる

最初から技術継承システムを作ろうと考えていたわけではありません。AIとの作業で困ったことを一つずつ解決していったら、人間同士の会話や社員指導も、残さなければ同じように消えていくと気付きました。

母艦、音声ナレッジ、Knowledge OS。今では別々の仕組みに見えますが、自分の中では同じところから始まっています。

ただ、音声を社内ナレッジとして残そうとすると、今度は誤変換の問題に何度もぶつかりました。技術用語、地名、人名、数字。録音すれば自動的に正しい記録ができるわけではありません。文字起こしだけを読めば、元の発言と違う意味に見えることさえあります。

音声入力を使い込むうちに、認識精度だけでなく、録音の始めやすさ、止めやすさ、元音声の保存、文字起こし後の確認まで含めて考えるようになりました。

その結果、今ではAIと一緒に、社内ナレッジを残すための専用レコーダーまで開発しています。

AIへの音声入力を使う

開始・終了の操作を改善する

社内会話の録音と文字起こしへ広げる

誤変換を何度も経験する

社内用の専用レコーダー開発へ進む

最初からレコーダーを開発しようと考えていたわけではありません。毎日使い、不便なところを一つずつ直そうとした結果、そこまで来てしまいました。

流れて消える情報や文脈を、あとから使える形で残す。それだけです。

土木設計でも、まず小さく試すようになった

このやり方は、Webアプリだけではありません。

図面をAIに読ませてみる。思うようにいかなければ、DXFを直接処理してみる。Pythonで小さな確認ツールを作る。CADやCIMの自動化を試す。

うまくいかなければ、原因を考える。別の方法を短時間で試す。それでも駄目なら、その方法には限界があると一度見切る。

できないことへ何十時間も使い続けるのではなく、小さく試し、早く判断する。AIは、この繰り返しを非常に速くしてくれます。

「分かってから始める」の順番が変わった

以前、新しいことを始めるときは、次のような順番を考えていました。

勉強する

理解する

実際にやってみる

今は、かなり違います。

まずやってみる

分からなくなる

AIに聞く

もう一度やってみる

少し分かる

何も理解しなくてよいという意味ではありません。仕事で使う以上、結果を確認し、重要な部分は人が理解して判断する必要があります。

ただ、「理解していないから始められない」という壁は、以前よりかなり低くなりました。

AIが、昔からの興味と今の仕事をつないだ

私は昔から情報処理に興味がありました。しかし、長く続けてきたのは河川を中心とした土木設計です。

以前は、情報処理と土木設計を別のものとして考えていたように思います。

生成AIが出てきて、その二つが急につながりました。

「こういう処理をしたい」と説明すると、AIがコードを作る。そのコードでDXFを処理し、CAD作業を自動化し、設計資料を整理する。うまくいかなければ、また相談する。

昔から持っていた情報処理への興味と、積み上げてきた土木設計の経験を、AIを間に置くことで一緒に使えるようになりました。

自分にとってAIとの相性がよいと感じる理由の一つは、そこにあるのかもしれません。

まだ未熟でも、次の一歩は踏み出せる

今でも、私はPython、HTML、GASのコードをゼロから自力で書けません。AIが示した修正箇所を、自分だけで直すこともできません。

それでも、何を作りたいのかをAIへ説明し、画面に出た結果を確認し、違っていれば問題を返すことはできます。そのやり取りを重ねることで、小さなツールだけでなく、会社のWebサイトを作り、更新することまでできるようになりました。

コードを書けるようになったのではなく、作るための会話と確認を続けられるようになったのだと思います。

それでも、以前なら専門外として諦めていたことへ手を出せるようになりました。完全に理解したとは言えなくても、実際に試したことで、「これはこういう仕組みなのだ」という感覚は少しずつ増えています。

その過程で得た考え方は、アプリの試作だけで終わりませんでした。AIとのコンテキスト管理になり、母艦になり、Knowledge OSになり、音声による社内ナレッジづくりにもつながりました。

最初から、そこまで考えていたわけではありません。

分からないまま始めて、困ったから工夫する。その工夫が、次の仕事でも使える考え方になる。振り返ると、ずっとその繰り返しでした。

まだ未熟でも、毎日情報を追い、小さく試し、失敗から学び続ければ、専門外だったことを自分の仕事へつなげられる。

AIによって変わったのは、答えを得る方法だけではありません。

分からないままでも一歩目を踏み出せるようになったこと。そして、失敗したあとも、その場で次の一手を考えられるようになったこと。

私にとっては、それがAIを使うようになって変わったことの中でも、かなり大きなものだと思います。