仕様書の基本と仕組み 第14章 バイブコーディングの活用

先日、池袋のジュンク堂に行きました。最近では技術書も Kindle 版で買う事も多く、そうなると Amazon 一択になってしまって物理的な書店には行かなくしまったのですが、大量の本をざっと眺めて背表紙を見てピンとものを買ってくる、という楽しみはやっぱり書店でしか味わえないものなのです。エンターテイメントと言えますね。
さて、ジュンク堂のコンピュータコーナーを見て、自著があったりなかったりして最近の傾向を確かめます。私の場合、C# 系の本が多いのですが、ジュンク堂の C# コーナーは C 言語といっしょくたになる位に小さくなっていて「ああ、タイトルに C# って付くと、それだけで本屋では隅に追いやられそうだ」と思ってしまう訳です。同人誌界隈の技術書典には行かないので、その傾向はわからないのですが、一般的にはそう、ということです。
他に何が増えているかというと「AI」です。もう「ChatGPT」すら古くなっているようなコーナーではありますが、兎に角エレベーター直近にあるコーナーは AI で占められています。あまり流行を追わなかったジュンク堂ですらそうなのですから、一般書店ならなおさらでしょう(ちなみに、一般書店のコンピューターコーナーは相当縮小されてしまって、Excel 本とか、スマホアプリの使い方とかが多いですね。まあ、作る側には回らないのと、長く続く不況のせいもあるでしょうけど、MOS をはじめとする資格本が多くなっています)。ジュンク堂の場合は、MCP があったはずなのですが、飽きてしまったらしくオライリーのプロンプトエンジニアリングの本が平積みになっていました。生成 AI そのものから、AI エージェントによる自動化が話題になり、AI 駆動という触れ込みから、再び「プロンプトエンジニアリング」を見直そうという向きになっています。さて、プロンプトエンジニアリングとはいえ、初期の ChatGPT の頃に流行ったなっちゃんって本じゃなくて、論文級のオライリーの本が置いてあるのが好感が持てますね。私も PDF で持っています。

コンピューター本の執筆をしている者としては(テクニカルライターと言うと足を使って取材をしている人を示しそうで、私の場合、モニタ上でぽちぽちやっていることが多く「テクニカルライター」というと語弊がありそうで怖いのですよ。コードは書くから「プログラマ」だし、名詞的には「ソフトウェア開発者」にしてあります。エンジニアは工学的な専門家になるでしょうから、「エンジニア」を付けるのもちょっと、という訳で)、AI の本を出せば売れるんではないか?とか「AI の本を出しませんか?」という話を聞いたりも聞かなかったりもするのですが、いえいえ、AI の本や「AI 駆動」の本はみなさんが書き始めていて、年末前には出版されてしまうので、いまから執筆しても無理なんですよ。それに、まあ、AI 駆動というのは、ちょっと前のプロンプトエンジニアリングブームの響きもあって、私的には避けてきたいところですね。あえて「○○駆動」とう枠組みに入れない方がよさそうです。

とは言え、

図解入門 よくわかる最新 システム開発者のための仕様書の基本と仕組み[第4版]

が棚に平置きになっておりました。平積みは水平に本を置くのですが、私としては棚に平置きになっているほうが嬉しいです。表紙が目の高さにあるので、平置きに目線をしたに下げるよりも、目線を上げて探すことが多いです。さらに言えば、スペース的にお得ですからね。他の本も並べられます。
どうやら、AI エージェント絡みで「spec 駆動(仕様駆動)」というワードが広がっています。いわゆる、ドキュメントに従って AI エージェントを動かそう、という話です。なんのことはない、従来型のウォーターフォール型や計画駆動を AI エージェントに置き換えただけなのですが、どうやら、最近の若い人には「仕様書を書く」ということが馴染みがないようで、仕様書の書き方がわからない、そもそも仕様や設計をまとめて書き下すことができない、という風潮があるようです。ようです、と言っているのは、目の前にしたことがない(…ことはないのですが、これは企業秘密としておきましょう、まあ、40代ぐらいの人でもできないし、60代近い人たちも、人まねでやっているだけで、理論的なことを学んでいない人が多いので、あまり、要件/仕様/設計が出来ている人はいません。アジャイルというか、カウボーイコーディングの人が多いのです。あまり関わりたいくないのですが、私の向こうがコーディングされている場合は ok です。被害を被らないし)訳でもないのですが、そのような傾向がみられます。

ちなみに、知らないことは罪ではありません。知らないことにより回りくどいことをやって失敗してしまうこともあるでしょうが、まあ、それは子供ならば仕方ないですね、というところです。大人ならば、まあ、馘になってしまうかもしれませんが、それも仕方がありません。
なので、知らないならば、知ればよいのです。「無知の知」もそうですが、無知だと思えば、知っておけば良いのです。概略でも知って、おけば、知ったかぶりをして、知っている人との話もあうでしょう。

さて、仕様書の話に戻りましょう。AI 駆動あるいは、AI エージェントの活用の仕方は、この本には書いてありません。この本では、仕様「書」や設計「書」などのドキュメントをベースにして開発が進んでいきます。ドキュメントに焦点を当てたのは、片方で、要件定義とか PMBOK の本とかが既にあったからです。当時の企画段階で、既に知識ベースの本はでていたので、じゃあ「書」にターゲットを置いてやってみましょう、と企画を通したのがこれです。幸い、といいますか、このドキュメントベースというスタイルは一般的には受けがいいらしく、第4版となって長く続いています。「改版のために、何か付け加えることはできませんか?」と言われて、章を少しずつ追加して今に至っています。

開発プロジェクトとしては第9章ぐらいで完結しています。その後の章は版を重ねるときに無理矢理追加してものです。無理矢理とはいえ、無理矢理を押したのは私の頭脳に対してなので、全体を通してみればなんとなく意味のあるような章立てにしてあります。ご安心ください。

第14章 バイブコーディングの活用

皆さんご存じの通り、秀和システムが潰れて、秀和システム新社になりました。面倒なので、前者を旧社、後者を新社と呼び分けますが、この手の図解シリーズはどうなるんでしょう?といのが一般読者的に興味があるところです。図解入門シリーズは、結構専門的なモノが多く著者も大学関係の人や専門家が多いんですよね。

それは、さておき、今後版を重ねるかどうか不明になってしまったので、第14章を追加してしまいましょう。せっかくなので、AI 駆動の話を絡めていきます。先に書いた通り「AI 駆動」という言葉はバズワードになりそうなので、ここでは避けておきます。「バイブコーディング(vibe coding)」も消えそうなのですが、プロンプトエンジニアリングぐらいは残るんじゃぁないでしょうか。

以下、阿部さんが顧客、加藤さんが開発マネージャーでお読みください。

保守を請け負っていて月1には WEB ミーティングをしているのだが、阿部さんからちょっと相談ごとが来た。
阿部「加藤さん、ちょっと相談があるんだけど。実は、最近うちの会社でも AI エージェントというモノを使い始めたんですよ。お客への案内メールをいままで Excel の VBA マクロを使っていたのだけど、ちょっと自動化をしようと思って書き直しているところでね。AI 駆動というのか、そのあたりなんだけど、ええと、それでね、加藤さんのところは使っている?」
加藤「なるほど。最近は AI が流行っていますよね。チャットで相談を受けたり、AI エージェントを使ってコーディングをしたりして、うちでも便利に使っています。Google とか OpenAI とかいろいろな会社のものがあるので、好きなモノで大丈夫ですね。有償版もあるのですが、まずは無料からどんな感じで作るか試してみるのがお勧めですよ」
阿部「そうなんだ。それは安心そうだ。それで、ちょっと相談があってですね」
加藤「はい、なんでしょう?」
阿部「システムの話じゃないけど、いいかな?」
加藤「もちろん、どうぞ」

加藤は嫌な予感がした。システムの話じゃないから、受注という訳でもなさそうだ。でも、システムが不具合がでたわけでもないし、打合せは月1にやっているわけだし。まあ、「AI エージェント」とか「AI 駆動」という言葉出てくる時点で、何かにハマった感じがする。

阿部「実は、Excel VBA のマクロを打ちの若手が書き直しているらしいのだけど、どうも、クラウドが必要だとか、データベースが必要だとか言い出してね。単にメールの自動配信なのだから、クライドを使わないといけない訳でもないハズなんだが、やたらに詳しく説得してくるんだよ。AWS とか Google Cloud とか、Azure とか、いろいろなクラウドがあるけど、AWS 一択だというんだよね。理由を聞くと、AI がそう勧めてくるから、という話なんだが、どう思う?」
加藤「なるほど。AI エージェントを使って、クラウドを選定しているんですね。まあ、AI エージェントは、いろいろな情報を集めて、最適なものを提案してくれるので、便利ですよね」
阿部「そうなんだ。それで、ちょっと相談があってですね。理由を聞くと、AI がそう言っているから、の一点張りで、料金とかコスト面はきっちりと出てくるのだけど、ランニングコストがどうなのかとか、そもそもクラウドにする必要があるかどうか、の検討が全くないような気がして」
加藤「AI エージェントは、あくまでも提案をしてくれるだけですからね。うまくプロンプトを入れると、比較をしてくれますが、それは試してみましたか?」
阿部「ざっと、比較はしているらしいんだけど。それに仕様書は Word 文書で統一しているのだけど、どうも markdown 形式じゃないと駄目と言いだしてね。うちのシステムは加藤さんのところで Word に統一して貰って随分整理されているのだけど、ここに markdown という形式を混ぜても大丈夫なものかな?」
加藤「markdown 形式自体はテキスト形式なので問題はないですね。Word と書き方が違うので、相互に完全に変換することはできないですが、AI エージェントを使って仕様書を読み込む点ではどちらの形式を使っても問題ないはずです」
阿部「そうなんだ。それは安心そうだ。じゃあ、これはこれでいいのかな。コスト面が気になってしかたながいのだけど。若手1人でいけるのならば、いいんだけど、専任じゃないから、仕事の片手間にできるだろうか。ああ、ほんとうは加藤さんのところに発注すればいい話なのだけど、実は、そこまで予算がなくてね・・・」
加藤「ああ、予算面は別にかまいませんよ。現在のシステムの保守と運用が続いているだけでひとまず十分ですから。私が気になるのは Excel VBA マクロの移植というところですよね。確かにメール関係をクラウドに持って行くのは今後の拡張を考えればそうかもしれないのですが、素直に言って、そこまでスケールを広げる必要があるのか?というのは疑問ですよね」
阿部「そうそう、そうなんだよ。いま動いている Excel VBA で十分なのに、それをクラウドに持って行くのは無駄じゃないかと思うんだよね。AI エージェントは、そういうことは考えないのかな?」
加藤「いやぁ、考えないことはないのですが、AI エージェントは提案をしてくれるだけでから、そこの切り分けは人間が判断するしかないですね」
阿部「そうか、やっぱり、人間がやらなきゃだめだよね。で、ここが相談なんだけど、その AI エージェントの件をちょっと見てくれないかな。コードのレビューというか、設計書のレビューというか」

ああ、そういうことか、と加藤は思った。保守・運用を担当しているのだから、ちょっと位サービスをしてもよいけど、コードレビューをするにはやりすぎかなと思うし、さてどうしたものか。阿部さんの話を聞く限り、どうも「AI 駆動」に何か幻想を抱きすぎているという気がする。いや、阿部さんは解っているらしいのだけど、若手の人が問題だろう。ひょっとすると、生成 AI とか AI エージェントに過大な期待を抱いているのだろう。

AI がなんでも答えてくれるわけではない。「幻覚(ハルシネーション)」という言葉は随分一般に浸透しけど、最近の「AI 駆動」の中の spec 駆動には勘違いが多い気がする。そこは設計書や仕様書をまとめていない世代には仕方がないが。いっそんこと、AI ペアプロの形でコードレビューを AI に任せるとか、チケット駆動式に思いついた機能を少しずつ実装していくほうがいいのではないだろうか。まあ、若手のコーディングスキルがどの程度かわからないが、あまり細々としたものをこちらに持ってきてもらうよりも、内製できるツールは内製して貰ったほうがいいし、ここは、ちょっとだけ労力がかけますか。

と、加藤が0.1秒で思ったかどうかは定かではないが、ちょっとした沈黙の後に加藤は答えた。

加藤「そうですね。まずは、AI エージェントに渡したプロンプトを見せて頂けますか。AI 駆動方式でやっているのでしたら、claud..md とか requirements.md とか、そういうファイルがあるはずですから」
阿部「そうですね。助かります。じゃあ、後でメールで送るので、ちょっと待っててください」

今月の月1のミーティングが無事終わり、加藤は阿部からのメールを受け取った。claud.md だけじゃなくて、requirements.md も添付されている。spec.md もある。excel_mail.md もあるし。spec_test_pattern.md もある。結構、いろいろなファイルがあるな。ああ、なんとなくわかった。「この匂いは、ChatGPT を使って腐ってしまっている匂いだぜ」、と脳内の声が響いてから、加藤は実装担当のプログラマである長島さんに言った。

加藤「長嶋さん、ちょっと悪いのだけど、この阿部さんのメールの件を見て貰えるかな」
長嶋「ええ!、まあいいんですが、これ残業ですか?」
加藤「いや、残業じゃないよ。ちょっとしたサービスだよ。まあ、1時間ぐらいで終わると思うけど」
長嶋「サービスですか、まあ、阿部さんの頼みならば仕方ないですよね。残業にならないように1時間だけってことでいいですね」
加藤「そうそう、1時間だけね。1時間だけ。で、内容は、AI 駆動でクラウドを選定しているらしいんだけど、ちょっと過大な期待を抱いているようで、そこをちょっと見て貰えるかな。プロンプトも添付されているから、そこも見て貰えると助かるよ」
長嶋「あ、ああああ、ああ、ああああああ・・・、そういうことですか。わかりました。ちょっと見てみますよ」

どうやら、長島さんには何か通じたようだ。弊社では、数か月間から AI エージェントで GitHub Copilot を使っている。GitHub Copilot は、Visual Studio Code の拡張機能として動き、GitHub Pro に月10$ で加入できる AI エージェント入門編として…という宣伝文句はどうでもいいのだが、入口には Copilot がちょうどよい。一応、Claude Code もにも加入して貰って試験的に使っている。ただ、長島さんが言うには「夜中に動かすような大規模プロジェクトならば、確かにペイができるんでしょうが、うちぐらいの中小規模のプロジェクトとなると、昼間に流すことが多いので、あまり綿密な設計に踏み込まないほうが結果的に効率がよいですよね。色々ですが、いろいろ」とのことだった。

それはさておき、夜中に AI エージェントを動かして、翌日に結果をみたときにコーディングの出力が止まっていることが多いそうだ。できたとしても頓珍漢なものがでてくる。まるで、3D プリンターのもじゃもじゃのようだが、そういうこともあるだろう。仕方がない。markdown の設計書をきっちりと直して、何回か流すとできあがるらしいが、そこまで労力を掛けるものかどうかが疑問だ。

長島「加藤さん、できあがりましたよ」
加藤「おお、早いね。ええ、早いというか、数行しか経ってないのだけど、できた?」
長島「ええ、まあ、ざっと見た感じでは、というか、もとのファイルを見ても仕方がないんですけどね。*.md ファイルがたくさんあるところを見ると、細かく設計を煮詰めすぎです」
加藤「やっぱり…」
長島「AI エージェントとか AI 駆動の書籍を読むと、設計をきめ細やかにと書いてあるものが多くて、以前のウォーターフォール開発を思わせるものが多いのですが、そもそも、そんなにきっちりと設計ができる訳がないんです。というか、きちんとできないから、アジャイル開発やチケット駆動がでてきたわけで、そこを無視して、AI 駆動だけ設計をきっちりとやろうとしても無理があるんですよ」
加藤「同意見だ」
長島「専門家ならばまだしも、素人…と言っていは言い方が悪いのですが、設計書を書いたことがない若い人の場合には、もっと逐一動作確認をしながら AI コーディングを進めていったほうがいいですよ」
加藤「なるほどね。確かにね。まあ、そうだよね。で、どうする?」
長島「最初のプロンプトはこんな感じで大丈夫ですよ」

設計.md
```
# Excel VBA マクロの移行

# 目的

- 既存の Excel VBA マクロのメール配信を、Python を使って書き直す
- クラウドは使わない

# 機能

- Excel VBA マクロの機能を Python に移植する
- メール配信機能を実装する
- 配信先は、Excel シートに記述してある
- 配信元は、コード内に .env として記述する
- メール配信の結果をログファイルに残す

# 制約条件

- クラウドは使わない
- メール配信先は 100 件程度
- メール配信は一日一回程度
```

長島「このぐらいで、十分ですね。もとの Excel VBA マクロの量がわからないので、なんともいえないのですが、クラウドに移行する必要がないところを見れば、そんなに件数は多くないでしょう。Excel VBA から Python に移行するのであれば、AI の力が借りれるし、少しずつコードを移植すれば確実に終わると思います。さすがに、一晩でおわりというわけにはいかないでしょうが。1週間あれば形にはなると思いますよ」
加藤「ありがとう。まあ、そうだよね。じゃあ、これを阿部さんに早速送っておくよ」
長島「加藤さん、ちょっと送るのは待ってくださいよ。即レスしてしまうと、IT 屋の立場がなくなりますからね、もうちょっと寝かせておいて、今週末か来週の月曜日の夕方あたりに送るってのはどうででしょう?それなりに仕事をした風にして」
加藤「ああ、確かに、じゃあ、メールで、月曜日に午後に自動送信にしておいて設定しておいて、と・・・」

果たして、阿部さんのところの若手がうまくいったかどうかは、来月のミーティングで聞いてみよう。そこそこの規模があれば、こちらで受けるとしようか、と加藤は思った。

カテゴリー: 開発 | 仕様書の基本と仕組み 第14章 バイブコーディングの活用 はコメントを受け付けていません

ChatGPT を使いながら短編小説書くと碇シンジ状態になれば成功

筒井康隆が90歳になってしまったのかというのと、六本木に松本零士展にいってみて生原稿を見たのと(あと、士郎正宗の原画展もあって)、ちょっとつらつらと文章書きを再開してみる。

文章自体は、技術書を年2冊のペースで書き続けているので、それほど苦労はしないのだが、技術書とは異なり小説の場合は気概というか、何か構えたところがあって、長年復活できないでいた。というか、復活は諦めていたのだ。

書きたいものが無いわけではなく、言いたいことを書く場所が欲しいのは確かで、依頼にせよあるい意味で惰性にせよ技術書を書いているのはそういう意味もある。ただし、完全に自由に書けるわけではない。あたり前だが、技術書なのだから嘘を書くわけにはいかない(結果的に嘘になってしまった=間違ってしまった、ことはあるかもしれないが)。自分なりに検証をしているし、過去に人の本を読み「このコードは動かしていないな?」とイライラしたことがあったので、自分のコードは全て動作をさせている(これも、たまに原稿上で直してしまうことがあって、コードが足りないことがあったりするもすのだが…ごめん、そういう理由で動かないことがあったのね、と昔の著者さんには謝りたい)ので、当然のことながら嘘や現実とは異なることは書けない。

じゃあ、小説の場合は嘘ばかりかというとそうでもない。当然のことながら誤字脱字を直さないといけないし、登場人物の整合性はあわせないといけないし、時代背景やら時代考証が必要なときもある。SF 小説であっても、あまりにも頓珍漢な科学技術を描くわけにはいかない(とはいえ、横田順弥のハチャハチャSF があるんだから、科学的の整合性をあえて外すパターンもある)。それは、どのようなものを自分が書きたいか、に依るだろう。
最終的に小説が売れるか売れないか、という点に拘ってしまうと、読み応えのある長編やら読者層にマッチした流行を取り入れたものやら、が出てくるわけだが。なに、「売れる」と言うこと自体は、「書く」時点で決まっているわけではない。むしろ「売れる」という現象は結果論である場合が多いので(企画ものは違うだろうが)、一定以上になる場合にはそれなりの捨て駒気分が必要なるだろう。
ちなみに、企画が通った技術書を書く場合、ある程度の安定収入(原稿費用みたいなもの)が入る。もちろん、それで開発者なみの給与になるかといえば、そうはならない。そうはならないので、主に技術書は「ボランティア」で書かれてといっても過言ではない。大抵の技術書はそうだろう。お疲れ様です。ひるがえって、私の場合はどうかというと、長年(20年は書いているので、長年といって差し使えないだろう)書いているので、どれぐらいの時間を技術書の執筆に突っ込むか、はある程度決めている。

閑話休題

生成 AI を活用して書き進める

プログラミングをするときに、生成AI あるいは AI エージェントを日常的に使っている人は多いだろう。生成 AI の活用は、2年前の新人教育から使っているのが、質問事項はほぼ「AI に聞け」ということにしてある。文法を全体を網羅して覚えるよりも、基本的な書き方だけ学び、解らなかったら AI に尋ねるということが効率的である。

さらに、今年の6月頃からだったか、AI エージェントが一般的になってきた。生成 AI 単体ではなく、ファイルやプロジェクトの内容を書き変えてくれる AI エージェントの存在は、コーディングというものを一変させている。AI 駆動と言う形で、最初に細かな仕様や設計を決める向きもあるのだが、私の場合は AI ペアプロがお勧めである。AI ペアプロの話は、また別の機会にやるとして、ここでは、短編を書くときの AI 利用についてちょっと気付いたことを書いておきたい。

1時間程度でざっと書き下すのが自分の時間の使い方としては合っているっぽい(長いと、書き飽きてしまうので)。なので、小説としては、2000字ちょっとぐらいの短編あるいは掌小説と言う形になる。ちょうど、星新一のショートショートか筒井康隆の短編ぐらいの長さだ。私としても、この位の短編が好きだった時期もあるので、長くて読みごたえがあるものよりも、小さくまとまって気の利いたものがよい。

文章を最近は VS Code で markdown 形式で書いている。どうやら、この書き方に慣れて来た。最初は、QX で書いたり、Word に貼り付けたりしていたのだが、VS Code + markdown + GitHub Copilot という形で技術書を書いている中で、最近ではこれが効率が良い。なんといっても、Copilot が次の文章を書いてくれるのがよい。

AI のサポートは、わざわざ AI に尋ねるのではなく、文章の続きを AI が差し込んでくれるのがむいている。特に技術書のように書き方が決まっている場合は、巷の Web サイトにある Microsoft や Google の公文書のような文体を差し込んでくれるので丁度よい。私の場合は「ですます調」で技術書を書くことにしているので、Web サイトの解説を AI が学習してくれて、それを私の文章に差し込んでくれるパターンだと、文章が無個性になって丁度よいのだ。「無個性」と言う書き方をしたが、プログラミングの本としては、ポリシーとして筆者の思惑をあまり主張しないようにしている。他の著者さんは違うかもしれないが、技術書は基本読み飛ばしが多いので、あまり文章に個性が出てしまうと読みにくくなってしまう。さらに言えば、私の悪文(多分悪文w)を編集者の方が直してくれている。読点が多いのが特徴で、語るように書くのもそうなのだが、長い文章の中で主語と述語がずれてしまうことがある。これ、語り言葉の場合はそう思えないのだけど、文章になると目立つのだ。特に、”熟読” している読者がいると、目立つ。そりゃ、文法上おかしいのだから目立ちますよね。そんなんに熱心に読まなくても大丈夫ですよ。さらっと、読み飛ばしてください。

で、生成 AI の場合は、なんとなく主語や前の文章を書くと、先の文を続けてくれる。この方式は生成 AI の Transformer に依存するものなのだが、いわゆるトークンとパラメーターの近似状態だけできまる。端的に言えば、top-p と温度というふたつの要素だけで、次の文章を決めることができる。もちろん、ランダム性が加わるので、かならずしも同じ文章になるとは限らない。そこで、ランダム性を広くとって SF 小説などを書くサポートに生成 AI をつけるとよいのである。

それと同時に、小説家にはそれなりに文体がある。例えば、2ch(あるいは 5ch)であるような村上春樹風の文章やら、星新一風の文章であるやらがそれだ。同じテーマを与えて「夏目漱石風に書いて」ということも AI には可能である。実際にどう似ているかは読むと解るのだけど、想像するに

  • 「夏目漱石」というとトークンに近い単語を拾ってくる
  • テーマとなる、文章に近い単語を拾ってくる
  • 両者に近い単語を、コンテキストのパラメーター(近隣値)に合わせて選び出す

という手順でやっているに違いない。実は人間が文体模倣をするときには同じことやっている。夏目漱石の小説を何冊かよみ、文章の繋がりを覚える。元の参考となる文章に、夏目漱石の文章の繋がり(時に副詞、助詞の繋がり、単語の選び方)を加えて、夏目漱石の文体に近づけるわけです。

さて、ここからやっと本題です。

生成 AI は近隣値(ベクトル)が近い形でトークン(単語)を選択するので、先立つ文章に続く生成される文章は、当然のことながら、学習元となる Web サイトや既存の公開されている電子文書(特に論文)に近い方になります。論文を書くとか技術文書を書く場合にはそのほうがよいでしょう。しかし、小説を書こうとなるとこれが一変します。独自性を出す、自分なりの文体を構築しようとしたときに、生成 AI がサジェッションする文章をそのまま採用することはできあません。定番の推理小説ならばいいのでしょうが、ちょっと毛色の変わった自らの文体を作りたい場合は邪魔になります。いえ、寧ろ、生成 AI がサジェッションする文章はそのまま採用できません。

というわけで、独自っぽい文体で書くと、生成 AI はこのように暴走をし始めます。

これ、GPT3 の頃にもよく見た現象ではあるのですが(top-p や温度を調節すると意図的に出すことができます)、GPT5やGPT4.1 でも同じ現象がでますね。つまりは、近隣値(ベクトル)に適当なものがなく、先に書いた文章を続けるしかない、碇シンジ文体になってしまうわけです。

要は、この状態になれば、あなたの文体は学習されていません、の印になるわけです。

カテゴリー: 開発 | ChatGPT を使いながら短編小説書くと碇シンジ状態になれば成功 はコメントを受け付けていません

筒井康隆の世界(再放送)を見ての感想を

筒井康隆の世界 – NHK https://www.nhk.jp/p/ts/7JPPP2R737/

去年の放送なので、現在は91歳ということになる。訃報は聞いていないので、まだ夫婦で老人ホームにいることになる。

実は『敵』を買って以来(しかも未読)な状態で、最近はあまり追ってはいなかった。現在90歳ということは、30年ほど前に新宿の紀伊国屋に身に行った筒井康隆は60歳ぐらいだったのかと。自分と30ほど違うとは驚きでもある。握手して貰った。

先日、「百年の孤独」を買い直した。ガルシア・マルケスがノーベル賞を取ったときに買っては見たものの暫く放置の状態で、引っ越しの折にBOOK OFF に売ってしまったような覚えがある。引っ越すときに、3,000冊の本を2,000冊位に減らした時にまぎれてしまった訳だが。あまり本は捨てるものではない。とはいえ、最近は電子書籍が便利になったので、Kindleに2,000冊ほど入っている(漫画も含めてだけど)。物理本は1,000冊弱にはなったのじゃないだろうか。で、買い直したのは、先日「百年の孤独」の100分の解説だったかで、大江健三郎や筒井康隆に影響を与えたとことを知ったのである。実は「百年の孤独」は1967年の出版で、私が生まれる前だ。ああ、そんなに古い作品であったのか、というのと大江健三郎(たぶん、万延元年のフットボールか燃え上がる木あたり)に影響を与えたとか、筒井康隆(たぶん、バブリング創成期とか)に影響を与えたとかという話になると、もう一回読んでみないとあかんだろうということになる。そうなると井上ひさしの「吉里吉里人」もそうじゃないだろうか、と思う訳で。で、まだ、「百年の孤独」は読んでいないのだが。

筒井康隆の初期作品に「東海道戦争」(1965年)がある。戦争を眺めるというパターンなのだけど、「銀河鉄道999」(1977年)にも戦争を眺めて食事をするシーンがある。松本零士は筒井康隆の5つぐらい下になるが、ほぼ同世代といってよいだろう。筒井康隆が90歳で存命なわけだが、星新一、小松左京、藤子不二雄、手塚治虫、とこのあたりの SF 世代はみな鬼籍に入っていしまっている。まあ、そういう意味では、夢野久作とか沼正三とか押川春浪なんかは、さらに年上なのだけど。そういう SF の技法に沿った形で描けるのは筒井康隆しか残っていないと言える。

ただし、「朝のガスパール」や「ビアンカ・オーバースタディ」のような書き方、さらに「モナドの領域」が現在の SF 小説(ラノベも含めて)にない訳ではない。むしろ、異世界転生ものだったり、ゲーム世界の拡張であったりするストーリーはそういう「メタ」的な視点が多いに含まれているし、それを知っていることが読者/視聴者の前提知識であったりする。例えば、涼宮ハルヒシリーズであったり、Reゼロであったり、SSSS.GRIDMANであったり、このすばであったり。主人公は意図的にメタ世界を意識している。もちろん、特別な能力があったりなかったりするわけだが、そういう現実的な世界とは別の世界に居ることを前知識として知っているという仮想世界、という読者との申し合わせは済んでいる状態になる。そのあたりは、「朝のガスパール」の連載時点でも、漫画の中に作者が登場したり(Dr.スランプとか、ブラック・ジャックとか)するシーンもあり、駒からはみ出したりするシーンがある。もちろん、そこを小説/漫画内に組み込み始めたは、果たして「朝のガスパール」だったのか、それともそれ以前に漫画があったのかは定かではない。

メタ空間という意味では、松本零士の銀河鉄道999もメタ世界であり、ハーロックやエメラルダスの世界と繋がっている。ラノベの小説でもあっちの主人公がこっちの小説にちょっとだけ出てきたりする。そういう仕掛けも読者にも既におなじみになっていて、みな了解の域に達している。

改めて筒井康隆が凄いのは、このメタ世界の小説をいくつも発表しているところだ。シリーズもので一本だけ書くのではなく、思いつく限りたくさん書く。これが凄い。

そうだな。また、短編を書く練習を再開してもいいかもしれない。

カテゴリー: 雑談 | 筒井康隆の世界(再放送)を見ての感想を はコメントを受け付けていません

「図解即戦力 アジャイル開発の基礎知識」のソフトウェア開発のための追記

本書の扱いとして、ソフトウェア開発におけるアジャイル方式をスクラムに限定することなく解説しておく、というのが本筋だったので、ソフトウェア開発そのものではなくマネジメント(スクラムマスターとかプロジェクトリーダーとか)に焦点が当たっています。昨今のアジャイル開発本がスクラムを中心にしていたので、元々の「アジャイル憲章」からスタートして、スクラム以外のアジャイル開発(XP、チケット駆動)を用いるのと、アジャイル開発自体は決して非PMBOKではない、ことを取り入れたかったので、PMBOK 用語を使っているという事情があります。

まあ、端的に言えばスクラム開発については、「ケン・シェーバー著のアジャイルソフトウェア開発スクラム一冊で十分じゃないですかね?」ってところからスタートしたので、こんな感じになっています。

端的に言えば、Software Development 以外を記述した本(教科書的な)なので、ソフトウェア開発については SWBOK あたりを読め、という形になります。これをスタートラインとしているので、本書の範囲としては、右中央の「アジャイル開発型マネジメント」に絞っています。

中央にある、PMBOKや実装ノウハウはソフトウェア開発において基本知識としてあるものとして、実際にプロジェクトを動かす場合に、計画駆動型にするかアジャイル型にするかという判断があります。これはアジャイル憲章にも書いてある通り、ドキュメントを包括するのか動くソフトウェアを優先するのかという “選択” になります。実は、ドキュメントのほうを優先する場合もあります。宇宙開発や原子力開発、航空機関係のシステムなどの人命が掛かるものは「ドキュメント」に基づいて合意を取る等の厳しいルールが課せられます。そういう場合は、到底アジャイル開発という訳にはいきません。もっと厳密な形でプロジェクトを走らせることが求められます。逆に言えば、人命に関わらないものに関しては随時動きを確認するようなアジャイル形式でよいのです。スピードが要求される広告サイトや商品販売、あるいは一時期的なイベントで集客を見込むようなWEBサイトなどはリリースまでの期間は短期であるほうが優れていると言えるでしょう。なんせ、WEBサイトの動きがちょっとおかしかったとしても人命が失われることはありません。更に言えばほぼリアルタイムに修正が可能です。

このように、マネジメント自体を計画駆動にするのか、アジャイル開発にするのかという選択肢は、エコシステムとして(まさしく、「アジャイルソフトウェア開発エコシステム」に書かれていることになりますが)どちらがより金銭的に有利なのかという話になります。

ソフトウェア開発そのものに結び付ける道筋

実際のところ、コードの実装者から見れば、それが計画駆動であるかアジャイル開発であるかの違いはありません。端的に、コードを書く、単体テストをこなす、を繰り返します。コード書く前に紙のドキュメントの有無であったり、詳細設計 “書” に基づくべきなのか、チケット駆動のようにざっとした箇条書きによってコーディングを行うかの違いはありますが、少なくとも現代においては「コードを書く」「単体テストを行う」という XP のノウハウを利用したほうがよいです。さすがに、いまどき、コンパイルが通らない状態でコードを書くことはないでしょう。昔は、コンパイル自体が長かった、あるいは大型計算機の使用時間待ちであったこともあり、コンパイルなしでコードを書く時期もありました。しかし、今、そんなことはしないでしょう。そういう意味で、XP のテストコードを書くといのは実装工程においては必須になってきます(テストコードを先に書くか、後に書くかという違いはありますが)。

対象読者ですが「コードが一定の品質以上で書ける」ことが前提となっています。マネジメント層(スクラムマスター、プロジェクトマネージャー、オーナーなど)はコード自体はまあいいのですが、開発者が読む場合はこれが必要条件になります。

本書の章をピックアップして具体的なソフトウェア開発(主に実装工程)に結びつけると、こんな感じになります。

第2章 スクラムとXP
先に書いた通り、単体テストが必須です。単体テストサイクルは各 xUnit のツールに従います。継続的なコード改善やコードの共有化においても、単体テストが有効に働きます。これは計画駆動、アジャイル開発に限りません。最近ならば GitHub Action などを利用して、コミット前にビルドやテストコードの実行を強要すればよいでしょう。
ペアプロについては、リモートでのペアプロが可能になっています。VSCode などでコードを共有してもよいし、Teams で通話を繋ぎっぱなしでペアプロをすることも可能です。実際、新人教育などでは2,3時間繋ぎっぱなしで、相手のエディタを表示してもらって操作することもやります。

第3章 チケット駆動、第4章 バックログ、チケット
「チケット駆動」ということになっていますが、実際はチケットの扱い方です。
作業を分割する方法として、WBS/チケット/タスク/プロセスなどの様々な呼び方があります。これらのタスクについては、スケジュールを確定させたい計画駆動と、途中で顧客の要望を取り入れたい=チケットが増加する可能性が大であるアジャイル開発との違いがあります。
また、スクラムではスプリントという期間を決めるのに対して、チケット駆動ではそれほど期間を区切りません。
また、チケットを共有する手段として、Backlog(という製品)や GitHub の issue の利用があります。以前ならば、Excel で課題管理をしていたところですが、昨今では Web アプリを使って複数名で共有するのが当たり前になってきています。
コーディングをする上でのチケットの扱いは、完了を明確にすることです。これは本書でも書いてある通り「単体テストが通った」ことを明確にするとよいです。客観的に完成したことがわかる目安を作っておくことが重要です。

第5章 自動テスト
いわゆる再帰テスト(繰り返しテスト)のやり方です。
モックの作り方などの具体例がでていないのはプログラム言語や動作環境によって異なるためで、割愛しています。
ざっと言えば、Web システムでの単体テストを Controller, Service, Web API 経由という分割した形にする。Servcie 単位が望ましいのですが、外部から curl などを利用した Web API 経由でもよいでしょう。ただし、データベースの中身のチェックがちょっと面倒になります。
デスクトップアプリでは、ユーザーが操作する部分でテストするのは人力となってしまうので、これもロジック部分を切り出して自動テストが可能な状態にします。場合によってはモックが必要になりますが、コツとしては「モックを必要としない単体テスト」と「モックを必要とする結合テスト」に分割するとよいです。
ちなみにモックを必要とする結合テストであっても xUnit のノウハウが使えます。
組み込み系はモックが必須になる(I/Oを叩く、タイミング調節など)ので、これはロジックを分離する形で単体テストができるようにします。これは必須条件ですし、単体テストを利用すれば、少なくとも実装期間が半分になるのでお薦めです。

第6章 スタンドアップミーティング
アジャイル開発で、朝会などが有効となっていますが、新型コロナの影響や海外チームを組むことは “同じ場所に集まることはできない” ので、別な方法をとります、ということです。
最近は、出社が強制する世の中に戻りつつありますが、要は遅延したコミュニケーションをどこまで考慮するのか?ということです。逆に言えば、本当に即対応(命に係わる現象)以外は、遅延を許容したほうがうまくいきます。
アジャイル開発スクラムで「スクラムミーティング」が強調されるため、同じ時間に同じ場所にいるということが重要そうに見えます。しかし、それはスクラムを採用したときの話であって、XPやチケット駆動、あるいは計画駆動の場合には必須条件ではありません。そのあたりを間違えると、無闇な “朝会” を開発者に強要することになってしまいます。というか、最近なっていますが。

第7章 タイムボックス
第6章のコミュニケーションに関わるものとして、締め切りを明確にした「タイムボックス」制を使います。つまり、いつまで作ればよいか?を明確にして、その間にあれこれと言わないということです。皆さん、プログラマはプロなんですから、途中でサボったりしませんよね、ということとサボっても締め切りには間に合わせてね、ってことです。途中経過は問わないのです。結果が重要です、という話ですね。
逆に言えば、未知なる要素が多いとこきはタイムボックスが有効に働きません。経験上、とあるコードが何時間、何日で作れるのかというのは「勘」を働かせることもありますが、過去の経験との比較をするのがベターです。あと、自分の実力を知るために PSP をしておくとよいです。うまくいかなそうなときは、いったんタイムボックスを外して、調査時間を決めて(時間は無限ではないので)、どのくらいで調べられそうかをチェックします。これは AI エージェントを使ったコーディングでも同じことが言えます。途中で迷路に入ってしまった AI エージェントを “時間” を区切って引き戻します。前回のプロンプトを無しにして、もう一度やり直しをすれば ok です。

第8,9章は割愛。主にマネジメントよりなので。

第10章 継続的リリース
DevOps が入れたかったのと、ソフトウェア開発者はどのように休日過ごすべきだろうか?というのを書くために入れています。
いまとなっては Google がやめてしまった 20% ルールですが、日々の仕事の中でなんらかの学習や実験をしておくとは非常に有効です。それも、最新情報を常に追うのではなく、仕事をしながら、つまりは仕事が8割で、未来への投資が2割ということです。未来の投資がなければ、成長がありませんよね。自分への2割の投資をしてください。
執筆時、「プログラマは休日、どうやて過ごせばいいだろうか?最新技術の勉強でしょ」という雰囲気があったので、それの反動です。最新技術を追う時間は業務時間にやったほうがいいです。休日はもっと自由な技術の追い方(休憩も含めて)をしてみてください。仕事とはいえ楽しくやりたいし、ましてプログラマという仕事は好奇心を突き詰めることもできるので “楽しい” 仕事です。そのための、ちょっとばかし辛い勉強や作業があっても全然大丈夫ですよね。ってことです。

このあたりの開発者寄りの部分は、また機会を見つけて書いていきましょう。なお、実際にどうすればよいのかというのを、https://openccpm.com で準備中です。

カテゴリー: 開発 | 「図解即戦力 アジャイル開発の基礎知識」のソフトウェア開発のための追記 はコメントを受け付けていません

AI エージェントでプログラマ向けタイピング練習アプリの試作とアイデアマラソン

ひさびさに “アイデアマラソン” の一環です。最近は起き抜けにスマホで Copilot を開いて、何かアイデアをまとめておきます。まとめるというか、アイデアを少し具体的に AI に尋ねて思考実験(壁打ちとも言う)をしておきます。Copilot の場合、あれこれと具体的なツールを作ろうとするのですが、そこは完全に無視をして、ちょっと抽象的で要件定義的な話に留めておきます。あと、実際に作るとなったらどんな機能があるのかを箇条書にメモをしておきます。

要件と機能が数行程度で固まったら、readme.md に書き込んで、vscode + GitHub Copilot でコードを書いて貰います。

# プログラマ向けタイピングゲーム

- コーディングのための英単語をが出てくる
- コンピュータの専門用語が省略形だけじゃなく、フルスペルで出てくる
- プログラミングで出てくるコードの一部がでてくる

## 機能

- 単語単位ではなく文字単位でキーのチェック判定をする
- 制限時間内のタイピングを競う

あらかじめ、Next.js を使うことは決めておいたので、React のプロジェクトだけは作成しておきます。

このぐらいのアプリだと、まあ UI は程よくできてくるのですが、動きが変なところが出てきます。今回のアプリで言えば、

  • キー入力が効かない
  • キーを入力している間にタイマーが正常に動いていない
  • 間違ったキーを押したときに、正しいキーを入れるまでカーソルを止めて欲しい

のように、動かせば一発でわかるようなバグが出てくるので、テスター役としてアプリを動かします。

バグの修正の場合、元の readme.md を書き変えてもよいのですが、所詮使い捨てのプロトタイプになるので、プロンプトで指示を出しています。

そういう意味では、自動化された vibe coding ではないのですが、私の場合はこのような AI ペアプログラミングのスタイルで十分です。要件定義や機能を厳密にまとめる必要はありません。そもそも、厳密に記述する必要がないし、厳密に記述することは不可能です。未来を見通せないので、プロトタイプ開発をしているわけですから。

半日ほど面倒を見て(片手間に)から、ほどよく動いたので、Vercel に公開しておきます。

https://for-programmers-typing.vercel.app

Vercel の場合、React プロジェクトが手軽に公開できるのが便利です。本格的に使うといろいろとあるのかもしれませんが、GitHub にアップロード → Vercel で自動的に公開、という手順が用意されているので、雑に公開してみるのもよいでしょう。

コードのほうは、GitHub に public にしておきます。private な状態でも Vercel に公開ができます。

https://github.com/moonmile/for-programmers-typing

typingData.ts に、出題するランダムな単語が書いてあります。このランダムな単語や文字列自体も Claude Sonnet が作ったもので、適当に問題が追加できるようになっています。 ひとまず、実際に動かしてアプリの雰囲気を確認したいときに、この方法が便利じゃないでしょうか?

参考先

アイデアマラソン研究所
https://www.idea-marathon.com/

アイデアマラソンというのは樋口氏が提案した、毎日アイデアを出してノートにつづっておくという習慣です。2000年頃の会社時代でもやっていました。営業とかでないので、プログラマだとアイデアを出しても仕事に直結する訳ではないのですが、日々の検索や最新情報を追うだけではなくて、「自分で作ったらどうなるだろうか」という形でメモっていきます。以前だと、実際に動かすことはできなくて思考実験で終わっていたのですが、AI エージェントと組み合わせれば、プロトタイプ程度であれば結構できあがりますよ、ってことです。出来上がったものを実際に仕事とかに使うかどうかは別ですね。

紙のノートとか使い場合はこんな風になります。

アイデアマラソンをやってみる – sowdatabase
https://sowrealyou.hatenablog.com/entry/2024/06/17/%E3%82%A2%E3%82%A4%E3%83%87%E3%82%A2%E3%83%9E%E3%83%A9%E3%82%BD%E3%83%B3%E3%82%92%E3%82%84%E3%81%A3%E3%81%A6%E3%81%BF%E3%82%8B

カテゴリー: 開発 | AI エージェントでプログラマ向けタイピング練習アプリの試作とアイデアマラソン はコメントを受け付けていません

.NET開発者じゃなくても利用できるタスクランナー fake の勧め

発端はこのポストから。

いわゆる、ビルドからデプロイ、テスト実行などを含めたタスクランナーですね。昔話をすると、いわゆる Makefile を使ったビルドが Java 環境で辛くなり始めたとき Ant が出てきて流行りました。中味は XML 形式で書かれていて、条件分岐や依存関係などが Makefile よりも書きやすいという触れ込みです。それを受けて、MSBuild が出来たわけですが、実は今となっては XML 形式というのは書きづらく、JSON 形式か YAML 形式(Docker など)が流行ったりしています。

一方で、Makefile を C 言語風に書くということで C++ 界隈では CMake が使われます。CMake は OpenCV などをビルドするときに外せない要素で結構複雑怪奇なのですが、関数形式であることと複数の Makefile をひとつにまとめられるという依存関係で重宝されています。

さらに傍流のところに Fake があります。Fake は F# 専用の(という訳でもないのですが)の Make ファイルで、ちょうど Ant/MSBuild の集約の仕方と CMake の依存関係をうまく吸収しています。とはいえ、F# 界隈でしか使われいないし、F# を使っていても実際のところは *.fsproj を使うので Fake を使うことは非常にまれです。と言いますか、今の今まで忘れていました。

https://fake.build/

fake コマンドをインストールする

いまひとつ、インストールの仕方が解り辛いのですが、以下のように dotnet コマンドで tool-manifest を作ってから fake-cli をグローバルにインストールします。npm でツールをインストールときと同じです。本来ならば、ローカルに入れたいところなのですが、パスを作るのが powershell では面倒なので -g でグローバルに入れたほうが楽です。

fake.build/guide/getting-started.html

dotnet new tool-manifest
dotnet tool install fake-cli -g

.dotnet/tools の中に fake.exe があります。fake.exe 自体は .NET 6 なんですが、まあ無視します。

PS H:\kitami\FolkBearsGroup\folkbears-android\FolkBears> gcm fake                                                                                            

CommandType Name Version Source
----------- ---- ------- ------
Application fake.exe 6.1.0.0 C:\Users\masuda\.dotnet\tools\fake.exe

バージョンはこんな感じです。

PS H:\kitami\FolkBearsGroup\folkbears-android\FolkBears> fake --version 
FAKE 6 - F# Make (6.1.3.0) (running on .NETCoreApp,Version=v6.0) (this line is written to standard error, see https://github.com/fsharp/FAKE/issues/2066)
FakePath: C:\Users\masuda\.dotnet\tools\.store\fake-cli\6.1.3\fake-cli\6.1.3\tools\net6.0\any\Fake.Runtime.dll
Paket.Core: 8.1.0

build.fsx を作成する

Makefile にあたるものを作成します。コマンドとしては dontet new fake でひな形が作成できるのですが、https://fake.build/guide/getting-started.html にあるコードをコピペしても構いません。

#r "paket:
nuget Fake.Core.Target //"
// include Fake modules, see Fake modules section

open Fake.Core

// *** Define Targets ***
Target.create "Clean" (fun _ ->
  Trace.log " --- Cleaning stuff --- "
)

Target.create "Build" (fun _ ->
  Trace.log " --- Building the app --- "
)

Target.create "Deploy" (fun _ ->
  Trace.log " --- Deploying app --- "
)

open Fake.Core.TargetOperators

// *** Define Dependencies ***
"Clean"
  ==> "Build"
  ==> "Deploy"

// *** Start Build ***
Target.runOrDefault "Deploy"

Target.create で、ターゲット名に従ってコマンドを書いてきます。大抵はShell.Exec でコマンドを実行します。依存関係が “Clean” ==> “Build” ==> “Deploy” のところで、ここではデフォルトで “Deploy” が実行されます。

実行するときは fake build のようにします。build は build.fsx のことなので、deploy.fsx とか setup.fsx とかも作れるはずです。

fake build

Android のビルドに使ってみる

では、手元の Android プロジェクトで使ってみましょう。手元の FolkBears プロジェクトは Kotlin で書かれているので、IDE エディタは Android Studio を使っています。コマンドラインからは gradlew コマンドを使いビルドができます。実機へのデプロイは adb コマンドを使います。

Gradle を利用してデプロイなどの機能を修正してもよいのですが、これを fake で作ります。

build.fsx

#r "paket:
nuget Fake.Core.Target
nuget Fake.Tools.Shell //"

#load "./.fake/build.fsx/intellisense.fsx"

open Fake.Core

Target.create "Clean" (fun _ ->
    printfn "Cleaning..."
)

Target.create "Build" (fun _ ->
    printfn "Building..."
    // gradlew でビルド
    Shell.Exec("./gradlew.bat", "assembleDebug") |> ignore
    // Shell.Exec("gradlew", "build")
)

Target.create "Default" (fun _ ->
    printfn "Default target実行中..."
    printfn "gradlewでAndroidアプリをビルドします"
    // gradlew でビルド
    let result = Shell.Exec("./gradlew.bat", "assembleDebug")
    if result = 0 then
        printfn "ビルド成功"
    else
        printfn "ビルド失敗"
        failwith "gradlewビルドが失敗しました"
)

// Android 実機にデプロイする
Target.create "Deploy" (fun _ ->
    printfn "Deploying to Android device..."
    Shell.Exec("./gradlew.bat", "installDevDebug") |> ignore
)

// 特定のデバイス(25041JEGR04165)にデプロイする
Target.create "DeployToDevice" (fun _ ->
    printfn "Deploying to device 25041JEGR04165..."
    // 環境変数でデバイスを指定
    System.Environment.SetEnvironmentVariable("ANDROID_SERIAL", "25041JEGR04165")
    let result = Shell.Exec("./gradlew.bat", "installDevDebug")
    if result = 0 then
        printfn "デプロイ成功 (25041JEGR04165)"
        printfn "アプリを起動しています..."
        // アプリを起動
        let launchResult = Shell.Exec("adb", "-s 25041JEGR04165 shell am start -n jp.mamori_i.app.dev/jp.mamori_i.app.screen.start.SplashActivity")
        if launchResult = 0 then
            printfn "アプリ起動成功"
        else
            printfn "アプリ起動失敗"
    else
        printfn "デプロイ失敗"
        failwith "デプロイが失敗しました"
)

// アプリを起動する(デプロイ済みの場合)
Target.create "LaunchApp" (fun _ ->
    printfn "Starting app on device 25041JEGR04165..."
    let result = Shell.Exec("adb", "-s 25041JEGR04165 shell am start -n jp.mamori_i.app.dev/jp.mamori_i.app.screen.start.SplashActivity")
    if result = 0 then
        printfn "アプリ起動成功"
    else
        printfn "アプリ起動失敗"
        failwith "アプリ起動が失敗しました"
)

open Fake.Core.TargetOperators
// 依存関係を削除して、Defaultが単独で実行されるようにする

Target.runOrDefault "Default"

色々と書いてありますが、これは vscode 上で GitHub Copilot + Claude Sonnet を使って書き足したものです。文法はは F# なので、既存の生成 AI のモデルに学習結果が含まれています。このために、Fake の書き方も的確に書いてくれます。

vscode の拡張には、Ionide.Ionide-fsharp を入れておくと便利です。

ビルド&実機へのデプロイを試してみましょう。

fake build -t DeployToDevice

無事、ビルドとデプロイが終わると次のところまで表示がでます。

警告が出ていますが、無視して大丈夫です。

Warning: Paket resolved a FSharp.Core with version '9.0.0.0', but fake runs with a version of '8.0.0.0'. This is not supported.
Please either lock the version via 'nuget FSharp.Core <nuget-version>' or upgrade fake.
Read https://github.com/fsharp/FAKE/issues/2001 for details.

どうやら現在の環境が .NET9 なんですが、fake が .NET8 のままっぽいです。バージョンを 8 のほうに揃えれば出なくなると思いますが、これは後で。

Shell.Exec でコマンドを羅列して戻り値を見るだけなので、結構使えるはずです。難点は文法が F# なところですが、Powershell や sh をちまちま書くよりはいいかもしれません。

これは Android 版なのですが、次は Xcode で Swift 版のほうのビルドをしたいんですよね。Swift 版のほうは macOS で動かさないといけないので、VNC 経由でやるか、mac mini 用のマウスとキーボードを使うとかという処で結構面倒なのです。ビルドとテスト実行ぐらいならば windows から ssh 経由でやりたいところなので、ここはもう少し試してみる予定。

カテゴリー: 開発 | .NET開発者じゃなくても利用できるタスクランナー fake の勧め はコメントを受け付けていません

見積もり依頼作成ツールの試作

ベータ版ではありますが、非IT業種向けの「見積もり作成依頼書ツール」 https://omitt-chan.vercel.app/ を公開しておきます。非IT業種向けということで、いわゆる発注者向けのツールです。

見積もり依頼書とは?

「見積もり依頼書」というのは、発注者がIT業者に見積もり依頼をするときの項目を書き連ねたものです。受注側が作成する要件定義や設計書に先立つものですね。普通は開発コンサルタントが発注会社に居て代筆をしたり、発注会社でのIT部門が作成したりするものです。

大手のIT会社だと開発コンサルタントが居て、営業が居て、という具合になりますが、20人程度の中小のIT会社だったり個人開発だったりすると、そういう風に作業分担ができるわけではありません。営業だったり要件のまとめだったり予算の見積もりだったりをひとりでこなすことが多いです。そんな中で、非IT業種である「見込み客」(まだ受注が決まっていないので、見込みでしかないです)に対して、中小や個人の場合はそんなに時間を掛けることができません。

時間を掛けることはできないのですが、営業活動はしないといけないよね、というジレンマがあります。

20年程前であれば、お客さんもITに詳しくなくてパソコンとインターネットがぎりぎりという方も多くいたのですが、最近であればスマホを使うは当たり前で、仕事でパソコンを使うし、インターネットで検索をするのは普通になってきています。ならば、ちょっとした「見積もり依頼者」ならば、見込み客のほうで書いて貰えるかもしれません。というのが、このツールの発想元です。

中小/個人の非ITとITをつなげる

予算が潤沢であれば、中小のIT業者に依頼をかけて1000万円以上で見積もりを掛けることも可能なのですが、実際はそうはいきません。せいぜい数百万、場合によっては100万以下のシステム開発からスタートするところでしょう。一方で、非ITとITをつなげるマッチングサイトもいくつかあるのですが、価格が安すぎるのが難点です。受注をする IT サイドから言えば、100万以下の案件はなかなか動きづらいところがあります(営業活動や見積もり作業も込みとなるので)。まして、10数万円ていどではITアルバイトのようなものです。実際に、小規模の作業であれば、ITアルバイト感覚で受注することもよいのですが、実はそれだけだと採算が合いません。

  • 発注者(非IT業者)からは、100万円程度で依頼を掛けたい。スケジュールは厳しくないが、それなりに品質を上げて欲しい。
  • 受注者(IT業者)からは、単発の仕事ではなくまとまった仕事で受けたい。タスクをまとめて、マルチプロジェクト/プロセスにして効率化しておきたい。

この2つを同時に実現することを考えます。そうすると、発注者としては、いくつかの不安点を解消する必要がでてきます。

  • 見積もりをして貰うときに、ある程度の予算を知りたい(IT業者に内緒で)
  • むちゃくちゃ安くなくても良い。しかし、1000万円を超える予算は取れない。
  • ITには詳しくないが、スマホのやブラウザの雰囲気は知っておきたい(IT業者には内緒で)

というように、いちいちIT業者に見積もりの問い合わせをしたり開発コンサルにお金を支払ったりしなくても、大まかな予算ぐらいは把握したいところです。いわゆる「市場的な相場はいくらかな?」というところですね。

現在、仲介業者のお陰で契約社員や派遣の給与が低く抑えられてしまっています。もちろん、契約社員や派遣でのよいとこはある(ピンポイントで働く、派遣会社が仕事を斡旋してくれるなどなど)のですが、中小や個人でのIT業者の場合は、あえて仲介を挟まないのであれば、挟みたくないのが本音でしょう。

  • ある程度の開発プロジェクトのマネジメントができるIT業者(中小はそれ)
  • 特化した技術を持ち、なんとか非IT系にリーチさせたい(個人開発者や数名の会社はそれ)

というIT業者と、非IT業者をつなげるのが目的です。

本ツールでできること

基本的に発注者(非IT業者)が使うツールです。

  • 作成した要件を要件入力チャットに入れていきます。まとまってなくて構いません。やりたいことを書いてくれれば ok です。
  • AI がチャットの内容を確認して、要望/機能要件/非機能要件/制約条件などの分類してくれます。
  • ある程度まとまったら「システム構成を生成」ボタンをクリックして見積もり依頼書を作成します。文章は、IT業者が理解しやすいように、システム要件などで分類されています。システムコンポーネントなどIT業者にしか伝わらない専門用語が使われていますが、大丈夫です。相手のIT業者ならわかってくれます。AI が IT業者向けに必要な情報を補います。

「見積もり依頼書」をコピペして、知り合いのIT業者にメールで送るか、クラウドワークスなどのマッチングサイトの要件と部分に貼り付けるか、入札に利用するか、してください。利用は自由です。

真ん中の「構造化要件」の内容は、ファイルに保存ができます。途中まで書いたらダウンロードして保存しておいてください。「読み込み」ボタンをクリックすると、保存したファイルを読み込んで、構造化要件を復元できます。

要件入力チャットの例

例を出しておきますので、コピペして使ってみてください。

https://omitt-chan.vercel.app/

例1 メール配信の自動化


- メールを配布するツールを作りたい
- 宛先はあらじめ Excel に登録しておいて、指定した時刻に配布できるようにする。
- 配布先はログに残しておく。
- 配布先にはチェックボックスがあって、配布するかどうかを選べるようにする。
- 毎日指定時刻に、定型文を送信する。このとき宛名は、Excel に記述した名前を使う。
- 配布する宛先は500件ぐらいある

見積依頼書

見積もり依頼書

【プロジェクト概要】
Webアプリケーションの開発をご依頼いたします。

【システム要件】
■ 機能要件 (6件)
・メール配布ツール: メールを配布するツールを作成する。
・宛先管理: 宛先はあらじめ Excel に登録しておき、指定した時刻に配布できるようにする。
・配布先ログ管理: 配布先はログに残しておく。
・配布先選択機能: 配布先にはチェックボックスがあって、配布するかどうかを選べるようにする。
・定型文送信機能: 毎日指定時刻に、定型文を送信する。このとき宛名は、Excel に記述した名前を使う。
・配布件数管理: 配布する宛先は500件ぐらいある。

■ 非機能要件 (0件)


■ 制約条件 (0件)


【技術仕様】
■ アーキテクチャタイプ: web
■ デプロイ環境: cloud

■ システムコンポーネント (5件)
・メール配布ツールフロントエンド (frontend)
技術: React, Bootstrap
概要: ユーザーがメール配布を管理するためのインターフェース。宛先の選択や定型文の設定が可能。

・メール配布ツールバックエンド (backend)
技術: Node.js, Express, Python
概要: メール配信ロジックを処理し、データベースと連携するAPIを提供。

・宛先管理データベース (database)
技術: PostgreSQL
概要: 宛先情報や配布先ログを管理するためのデータベース。

・クラウドインフラストラクチャ (infrastructure)
技術: AWS, Docker
概要: アプリケーションをホスティングするためのクラウド環境。

・セキュリティ対策 (security)
技術: OAuth2, SSL/TLS
概要: データの保護と不正アクセス防止のための対策。

■ ネットワーク要件
・インターネット接続が必要
・APIレスポンスは1秒以内

■ セキュリティ対策
・ユーザー認証と権限管理の実装
・データ暗号化とバックアップの実施

■ スケーラビリティ考慮事項
・負荷分散を用いたスケーラビリティの確保
・データベースのリードレプリカを利用した読み込み負荷の分散

【その他】
ご質問やご相談がございましたら、お気軽にお声がけください。

例2 炉心計算と制御棒配置の比較研究

- 原子炉の制御棒の配置比較システムを試作する
- 拡散方程式を使い、原子炉内の中性子の分布を計算する
- 制御棒の配置を変更することで、出力の中性子の分布を調整できるようにする
- 制御棒の配置パターンを色々変えた状態で、臨界ができるかチェックする
- 配置パターンによりシミュレーションデータを出力する
- 各実験により、シミュレーションデータを比較できる機能を持つ
- ログイン機能を持ち、各ユーザーが実験データを別々に保存できる

見積依頼書

見積もり依頼書

【プロジェクト概要】
オンプレミスシステムの開発をご依頼いたします。

【システム要件】
■ 機能要件 (7件)
・原子炉制御棒配置比較システム: 原子炉の制御棒の配置を比較するシステムを試作する。
・中性子分布計算: 拡散方程式を使い、原子炉内の中性子の分布を計算する。
・出力調整機能: 制御棒の配置を変更することで、出力の中性子の分布を調整できるようにする。
・臨界チェック機能: 制御棒の配置パターンを色々変えた状態で、臨界ができるかチェックする。
・シミュレーションデータ出力: 配置パターンによりシミュレーションデータを出力する。
・データ比較機能: 各実験により、シミュレーションデータを比較できる機能を持つ。
・ユーザー認証機能: ログイン機能を持ち、各ユーザーが実験データを別々に保存できる。

■ 非機能要件 (0件)


■ 制約条件 (0件)


【技術仕様】
■ アーキテクチャタイプ: on_premise
■ デプロイ環境: on_premise

■ システムコンポーネント (5件)
・Webアプリケーション (frontend)
技術: React, HTML5, CSS3
概要: ユーザーが原子炉制御棒配置を操作・比較するためのブラウザベースのインターフェース。

・シミュレーションエンジン (backend)
技術: Python, Flask, NumPy
概要: 中性子分布計算や臨界チェックを行うロジックを実装したサーバーサイドコンポーネント。

・データベース (database)
技術: PostgreSQL
概要: ユーザー情報やシミュレーションデータを保存するためのリレーショナルデータベース。

・サーバーインフラ (infrastructure)
技術: Linux, Docker
概要: システム全体をホストするための物理サーバーまたは仮想サーバー。

・ユーザー認証システム (security)
技術: OAuth2, JWT
概要: ユーザーのログイン機能を提供し、データのセキュリティを確保する。

■ ネットワーク要件
・低遅延のネットワーク接続が必要
・セキュアなVPN接続を使用して外部からのアクセスを制限

■ セキュリティ対策
・ユーザー認証とアクセス制御の実装
・データ暗号化を使用して機密情報を保護

■ スケーラビリティ考慮事項
・シミュレーション負荷に応じてサーバーリソースをスケールアップ可能
・データベースのシャーディングを考慮し、大量のデータに対応

【その他】
ご質問やご相談がございましたら、お気軽にお声がけください。

今後の拡張予定

見積もり依頼書までできたら、発注側(非IT業者)で、ざっとした要件定義やざっとした概要仕様書まで作っておきたいところです。

依頼書や要件定義、かんたんな概要設計をもとに、AI で見積もりを立てます。それのベースに、スケジュールや相見積を作成するところまで持って行きます。

その後に、発注者(非IT業者)と受注者(中小のITや個人開発者)のマッチングを考えたいところです。

カテゴリー: 開発 | 見積もり依頼作成ツールの試作 はコメントを受け付けていません

個人開発者のマルチプロジェクトのマルチプロセス化の勧め

個人開発者(いわゆるフリーランス)と、中小企業の開発者は、ひとつのプロジェクトに掛かりっきりということがまずありません。いくつかのプロジェクトを掛け持ちすることになります。

前提

実は、大会社の開発者(システムエンジニアとかマネージャではなく)や派遣社員や契約社員の場合には、一定の期間一つのプロジェクトに拘束されるというのが常です。特に、派遣社員や契約社員はそうなのですが、中小企業というか20人ぐらいまでの小規模のIT会社の場合には、一つのプロジェクトに縛られることはまずありません。色々なプロジェクトを平行に動かす必要がでてきます。

というのも、

  • 開発プロジェクトの規模が小さく、ひとつのプロジェクトに貼り付けにするほど予算がない。
  • 請負開発を受注する場合、社員=開発者が少ないので複数プロジェクトに配員せざるを得ない

という現状があります。発注側からみてフルタイムで働いているように見えて、内実は別のプロジェクトも抱えている、というのが現状ですよね。マネージャーや営業レベルだと複数のプロジェクトが動くのは普通なのですが、開発者の場合は複数プロジェクトというのは大手であれば稀だが中小であれば当たり前だったりします。

この認識を前提としていきます。

当然、個人開発者の場合も同じで、派遣や契約社員にならないのであれば、複数のプロジェクトが掛け持ちになるのが普通です。フリーランスなのでハンドリングを自分でやるのが中小の社員とは違いますが、マルチプロジェクト化します。

スクラム方式ではうまくいかない

基本的に、アジャイル開発スクラムの場合には、ひとつのプロジェクトに集中できることが前提となります(実際はどうなのかは別ですが)。自分の時間をコミットするので、2週間なりのスプリントができるし、そのプロジェクトの中で課題(バックログ)のやりくりをします。

ですが、先の中小や個人開発者の場合は、ひとつのプロジェクトに集中できるわけではないので、このスクラムの前提が崩れてしまいます。

と常々思っていたのですが、その理由が解説できそうなので、メモとして残しておきます。

理由はまさしく先に書いた通り、ひとつのプロジェクトに集中できない、つまりはコミット率が低くなってしまうので、スクラムの柔軟さが失われてしまうということです。なので、複数プロジェクトを掛け持ちしているメンバーがスクラムチームにいると失敗しがちですね。巷でいうスクラム開発が失敗したり、うまくいかないと思われている理由はこれでしょう。

マルチプロジェクトをマルチプロセス化する

ひとりの開発者が複数のプロジェクトを掛け持ちしていることを考えてみましょう。ここでは、経費精算とか社内での勉強会とか定型業務は別とします。一般的な開発プロジェクトのようにスタートとエンドが決まっているものを示します。

開発者が、A,B,C という3つのプロジェクトを掛け持ちしてる場合、複数の時間の使い方が考えられます。

  • Aプロジェクトを終わらせて、Bプロジェクトを終わらせて、Cプロジェクトを終わらせる
  • 1日を3分割してA,B,C のプロジェクトを少しずつやる

理想的なプロジェクトの形式で進めれば、どちらの方法もA,B,Cプロジェクトを終了させることができます。実際のところ、プロジェクトが1週間程度のものであれば、シーケンシャルにA,B,C と進めていったほうが早く終わります。頭の中でプロジェクトを切り替える必要がないのですから、それぞれの専任していると同じになります。

しかし、実情としては後者のようにA,B,Cのプロジェクトをちょっとずつやることになります。これは、各プロジェクトが長期に渡るのも理由なのですが、実際には途中に進捗会議があったり、客の回答待ちになったり、開発環境の購入待ちになったりします。その合間に別のプロジェクトをやったほうが時間効率がよくなる…ように見えるためです。

1日を3分割するのであれば、A,B,C の3つのプロジェクトを廻せそうですが、お客との会議や回答待ちなどを考えると、必ずしも1日を3分割にする必要はありません。むしろ無駄ができそうです。

なので、プロジェクトという単位ではなく、プロジェクトにプロセス/タスクという単位に区切ります。実際のところ単一プロジェクトであっても WBS/バックログ/チケット、という形で作業分割を利用するので、それと同じ状態です。ただし、複数のプロジェクトであり複数のタスク(プロセス)であるということが違います。

タスクを細かく分割すると、A,B,C のプロジェクトの切り替えでセットアップ時間(仕事の切り替え時間)が発生してしまいますが、そこは個人開発者の場合は休憩時間や昼休みなどを利用します。また、タスクに分けたときに、”タスクの途中でも切り上げられる” & “タスクの途中でもうまく再開できる” 仕組みを用意しておきます。理想を言えば、ひとつのタスクが仕上がるまで掛かりっきりになるのがベターではあるのですが、そこまでタスク/チケットを細かくできないことが多く、タスクの中の作業単位(TODOや箇条書き)で切り替えができるとよいです。

複数プロジェクトのタスクを渡り歩く

個人開発者であれば、身がひとつなのですから、Aプロジェクトのタスクをやっている間は、BプロジェクトやCプロジェクトのタスクはお休みなります。一見、マルチタスクで動いているようには見えますが(今後 AI エージェントの活用次第ではそれができるかもしれませんが)、個人の時間軸から言えばシーケンシャルにこなしているだけです。

この場合、A,B,Cの開発見積(予算、金額)はどうなるでしょうか?

プロジェクトの作業見積をする場合、大抵はプロジェクトに専任であることが前提となっています。スクラム方式で言えば、1か月20日8時間勤務ですから、160時間が基準値となります。

これを基準としたとき、A,B,C プロジェクトを掛け持ちする場合を考えてみましょう。

  • Aプロジェクト 80h
  • Bプロジェクト 40h
  • Cプロジェクト 40h

という見積もりを立てることが多いですよね。プロジェクトマネージャーやプロジェクトリーダー役をやったときに、マルチプロジェクトになってしまった場合にはこんな感じに割り振ってしまいます。

大抵の場合、作業時間 x 単価ということになるので、AプロジェクトはBプロジェクトの2倍の予算が掛かります、とお客に説明するわけですが、果たしてそうなるでしょうか?当然のことながら、A,B,C のプロジェクトのお客さんは別々で、互いに顔を合わせることはありません。場合によっては、開発者が自分のプロジェクト(Aプロジェクトとか)に専任していると思っているかもしれません。そうです、いわゆる「官庁プロジェクトの開発者は3倍働く」わけですが、それはまた別の話。

割り振った時間や予算は2:1:1のように分割されますが、実績ではそうはなりません。計画上は2:1:1の比率になるのでしょうが。例えば、Bプロジェクトがちょっと遅れ気味の場合は、Aプロジェクトを少し抑え気味にしてBプロジェクトに力点を変えますよね。Cプロジェクトがさっくりと終わるようであれば、そのままA,Bプロジェクトに作業時間を割り振ってしまうことも稀でありません。そんな形で、A,B,C プロジェクトに費やす時間を開発自身が割り振り直してしまいます。

マルチプロジェクトが安全バッファとなる

過小見積をしてしまうと、A,B,C の3つのプロジェクトが炎上してしまって、どのプロジェクトも立ち行かなくなってしまいます。しかし、それなりに規模見積もりがあっている場合は、A,B,C の実績は平均値を上下する程度で済みます。平均を上下した場合、先のように他のプロジェクトにリソース(この場合は時間)を割り振ることができます。つまりは、CCPMのプロジェクトバッファと同じように、マルチプロジェクト自体が安全バッファとなるのです。マルチプロジェクトの場合は、プロジェクトごとにバッファを持たせる必要がなくて、マルチプロジェクト全体のバッファを持たせればよいということになります。これは個人開発者の場合は、土日祝日だったりするわけです。忙しいときは仕方がないので土曜日に少し足しておくか、という感じです。

制約理論的には、プロセスのバッファをひとつにまとめてプロジェクトバッファとしているのですから、複数プロジェクトのバッファをひとつにまとめて、マルチプロジェクトのバッファつまりは開発者自身のバッファということになります。つまりは、単一プロジェクトに掛かりっきりになるよりも、ある程度マルチプロジェクト化したほうが安全ということです。もちろん、同時に炎上しないように注意する必要はありますが。果樹園農家で、ひとつの果物に集中するのではなく、リスク分散して複数の果物を作るのに似てますね。

カテゴリー: 開発 | 個人開発者のマルチプロジェクトのマルチプロセス化の勧め はコメントを受け付けていません

粗大ごみの金額が検索できるサイトの試作

去年だと思いますが、生成AIがちょっと流行った頃に(今はAI エージェントが流行っている)、東京都のとある区で粗大ごみの分類を検索する入札が行われました。で、どこかの会社が受けたと思うのですが、検索した適合率が90%程度だったので採用にならず、というのがありました。

ちょうど、その頃に Azure OpenAI 本を出版したときもあって、この第10章に Function Calling の活用があって、それを使うともう少し精度ができるなぁ、と思った次第です。

OpenAI の Function Calling は AI のプロンプト上から特定の関数を呼び出すことができる仕組みです。ちょうど JSONP のような形でコールバックを返してくれます。で、いまでは MCP (Model Context Protocol) サーバーを立てるというパターンもあるので、Function Calling を使った RAG (Retrieval-Augmented Generation)にするか MCP サーバーにするかというところですが、このあたりはチャット部分を自前で作成するか、Claude Desktop などを利用した既存のチャット/プロンプトを使うか、という形で分かれます。

板橋区粗大ごみの分類を取得

粗大ごみの分類は各自治体でかなり違ってきます。そのために分類も違ってくるので、なかなか統一できません。

粗大ごみ(申込制/有料)・料金検索(AIチャットボット)|板橋区公式ホームページ https://www.city.itabashi.tokyo.jp/tetsuduki/gomi/sodai/1001868.html

ひと世代前のチャットボットが流行りなのですが、まあ、ひと世代前なのです。

ピンポイントで検索できるものはいいのですが、ちょっと込み入ったものだと微妙です。この例では「ガラス」に引っ張られていますが、「机」のほうがよいですよね。実際に「机」の分類があります。

結局めんどうくさくなって、PDF の一覧表から検索したりします。

実は分類は400弱ぐらいしかないので、そう多くないです。要は利用者が自然言語を使って質問しているところに、サイト側で「キーワードマッチ」しかしていないのが問題です。というか、当時のチャットボットはそういうものだったので、これでも十分なような気がします。

が、生成AIを使っていけば、もう少し利用者側に便利できるのでは?と思ったのが、RAG や MCP サーバーの登場というところです。

粗大ごみの分類DBを作る

粗大ごみの分類が PDF で提供されているので、これを SQLite のような DB で扱えるようにします。この作業を ChatGPT を使おうと苦戦したのですが、あえなく挫折しています。どうも PDF の表面は表形式に見えるのですが、中身がぐちゃぐちゃになっているようで ChatGPT が python で読み込もうとして失敗してしまいます。画像読み込みを試せばよかったのですが、まあ、数も400行位だしということで、手作業で Excel に直しました。

板橋区粗大ごみ.xlsx

試しに分類をやってみたいという奇特な方はこれを使ってみてください。自分の自治体に CSV 形式であればそれを使ってください。

板橋区の場合は「名前」「金額」「特記事項」となっています。まあ、中身をみるとわかるのですが、特記事項に品名っぽいものが書いてあったり、名前にサイズ(机のサイズとか)が書いてあったりしてかなり混乱しています。この手のやつは自治体では仕方ないことで、まあデ庁の標準化は大変だろうな、といいますか、そもそもデ庁主導では標準化できないだろう、などと思ったりししつつ、さてどうしたものかと考えるのです。

面倒な場合は Excel にした後で検索すれば一発なので、うまくキーワードが検索できればそれで十分ですよね。

ユーザーインターフェースを考える

最近は要件定義や設計を readme.md に残すようにしています。

# 粗大ごみ検索システムの試作

粗大ごみの分類を LLM を既存データベースを組み合わせて金額を調べるシステム

## 概要

- 粗大ごみの分類は、既存のデータベース(SQLite)を使用
- フロントエンドの UI は Chat を使う
- フロントエンドは OpenAI API を使うと高くなるので、ローカル LLM を利用する

## ユースケース

例1
- ユーザーが「ソファを捨てたい」と入力
- システムが「ソファは粗大ごみです。料金は500円です。」と応答

例2
- ユーザーが「冷蔵庫と洗濯機を捨てたい」と入力
- システムが「冷蔵庫の料金は1500円です。洗濯機の料金は1000円です。」と応答

例3
- ユーザーが「本棚を捨てたい」と入力
- システムが「本棚の高さは200cm以上ですか?」と応答
- ユーザーが「はい」と入力
- システムが「本棚は粗大ごみです。料金は800円です。」と応答


## 技術スタック

- フロントエンド: React
- データベース: SQLite
- LLM: Local LLM + Next.js
- API: OpenAI API + Laravel

こんな風にユースケースを書いておきます。例をいくつか書いておいて、こういうプロンプトを入れたらこういう形で AI が返してくれる。再びチャットを続ける、という形でユーザーインターフェースをデザイン=設計していきます。

以前ならば、このユースケースを設計書に落とし込んで、ルールベースに直して、実装してという手順になり、それを自分でやらなくてはならないのですが、AI エージェントのおかげでこのあたりの手順を AI に任せることができます。漠然としたユースケースなので自動化という訳にはいきませんが、以前よりも実装スピード=プロトタイプが出来るスピードが早いです。

  • ユースケースを示しながら、設計を AI と相談する
  • ユースケースが実験できるような、プロトタイプの画面を AI に作成して貰う
  • 設計に従って、AI にコーディングしてもらう
  • 細かい動きを AI に修正してもらう

という形で、ほぼほぼ AI がコーディングを担当していきます。私は、動作確認をしたり、プロトタイプを見て感想を言ったり、テストするポイントを AI に伝えたりという役目です。

AI コーディングには Claude Sonnet を使っていますが、こんな風なイテレーション開発の場合にはこれで十分です。

利用者のプロンプトを解釈する

ユースケースから考えると、プロンプトは利用者のブラウザで動かすことになります。

  1. 利用者が、プロンプトを開いて「ソファを捨てたい」と入力する
  2. 「ソファを捨てたい」から「ソファ」の単語を抜き出す。
  3. 「ソファ」にマッチするデータを、粗大ごみ DB から検索する
  4. 「ソファ」の金額が検索できる
  5. プロンプトが「ソファの金額は400円です」と回答する

というユースケース記述ができます。「ユースケース記述」は要件定義やシステム概要設計で使うときの UML のひとつです。

さて、自然言語で「ソファを捨てたい」と利用者が入力するわけですが、単純な単語のマッチングではなくて、AI を使って「ソファ」という単語を取り出します。つまりは、プロンプトのプレ処理に OpenAI API を使う訳です。AI の活用では、こういうように文章から重要な用語を抜き出す用途にも使えます。

が、いちいち OpenAI API を呼び出していると課金されて高いですよね(実は ChatGPT5 の値段が相当安いので、呼び出しても大したことはないのですが)。なので、ここでローカルLLM を使います。ローカルLLMを使えば課金が一切なくなるので、API の呼び出し放題です。

と、いうところまで構想をたてて、まずは laravel の webapi を作成中です。もう少しできあがったら追記します。

ローカル LLM には LM Studio あたりを使う予定。モデルは Google の gemma あたりで十分です。

カテゴリー: 開発 | 粗大ごみの金額が検索できるサイトの試作 はコメントを受け付けていません

夏休みの計画を AI(Copilot) を使って立てよう

毎年、夏休みの宿題についてちょっとだけブログアクセスが増えます。で、今回は、AI(Copilot)を使って計画を立ててみましょう。AI は何でもいいのですが、Windows 11 に付属している無料版の Copilot を使います。

課題一覧を読み込む

ここに中3の夏休みの課題一覧があります。中学3年生の時期は高校受験を控えているので、この手の夏休み課題は少なめにして欲しいのですが果たして…多いですね。塾とか部活とかいかないといけないのに。愚痴を言っても仕方がないので、とっとと計画だけでも立ててみます。

計画を立てる意義としては、

  • 全体のボリュームを把握する
  • 漠然とでもいいので、見通しを立てる
  • 途中で見通しとずれているかを確認する

ということが大きいです。なので、従来のウォーターフォール開発のような詳細な計画を立てても仕方がありません。夏休みは長い(とはいえ、今日は8/7なのですが)ので、隙間時間をつかって課題をこなしていきましょう。

最近の AI は OCR 機能がついているものが多く、この手の紙のプリントをスマホで撮って、Copilot のプロンプトに貼り付けます。

大抵の場合はいけるんですが、どうやら「数学」しか読み取れてないので、プロンプトで指定します。

国語、社会、数学、理科、英語、保健体育、技術、家庭の項目を読み取って。

最初から読み取れよ、という気持ちをぐっと抑えて。

念のため、項目をチェックしてください。AI & OCR 読み取りに失敗しているところ(理科の部分)もあるので、これを補足して箇条書きにします。

科目ごとに箇条書きにして。

ほかにも、理科の項目を付け足します。

理科は、「3章の小テスト」「イオン式のテスト」
にして。

Copilot の箇条書きが更新されます。

超概算見積もりを出す

科目ごとにいくつかの項目がでたので、全体で概算を出します。これはIT開発のプロジェクトでも同じです。要件定義の段階でいくつかの機能要件とかを出して概算見積もり(予算、期間)を出します。

夏休みの宿題の場合は納期=2学期の始まりが決まっているので、全体のスケジュール自体はあまり立てなくてもいいです。途中に塾とか部活とか遊びとか花火大会とかカラオケが挟まるわけで、その合間にアジャイル的に夏休みの課題をこなします。

科目ごとに、どれくらいの時間がかかるか見積もって。

子供の実力によってばらつきがあるとは思うのですが、ひとまず概算だけだしてもらいます。

ざっとみると、約23~34時間程度ということなので、寝ずにやれば1日ちょっとで終わりますね。いや、最悪の学生症候群を使ってもいいのですが、まあ、超概算的にはこれで十分でしょう。夏休みの宿題は事務仕事とは違うので、

  • 何かこなせば終わる宿題
  • 何か考えないと前に進まない宿題

という2種類に分けておきます。前者の場合は、夏休みのワークとか英語の宿題とかがそれにあたります。これは逆に時間を掛けないと終わらない項目なので、ちょっと計画立ててやらないと駄目です。逆に、後者の場合は何か考えないと終わりません。漠然と机の前に座っているだけではだめで、能動的に頭を働かせる必要があります。後者の場合は、国語の読書紹介文や社会の税の作文にあたります。これは、方法がわかってしまえば1時間弱で終わります(大人がやれば)、逆に何をやったらわからない場合には1日経っても終わりません。

重たいタスクをピックアップする

いわゆるチケット駆動的に夏休みの宿題をやっていきましょう。科目ごとに概ねかかる時間がわかったので、それぞれをチケットに分けていきます。

チケット駆動の場合は、チケットの仕事量をできるだけ揃えた方がいい(チケットの数だけを勘定したいため)ので、夏休みの宿題の場合は「1チケット=1時間」を目安にしていきます。

例えば、国語の読書感想文のは3-5時間かかるということになっているので、5時間の5チケットということにします。

チケット駆動を利用します。 1チケット=1時間を目安にします。

Copilot がチケット単位にわけてくれます。ここから国語のチケットを書き出してもらいます。

国語の4チケットの内容を書き出して。

国語の読書感想文を4チケットに分けて、それぞれの作業内容を書き出してくれます。これは、チケット駆動のチケットの書き出しにあたります。チケット駆動の場合は、プロジェクトが進む中でチケットを書き出すことが多いのですが、夏休みの課題の場合は、全体の総量がわかっているので、このようにチケットを分割してしまったほうが早いです。全体を分割するときに、以前までは付箋を使って計画を立てていたのですが、最近ならば AI を使えば便利です。

タスクの詳細を掘り込む

ここまでがいわゆる概要設計というやつなので、次は読書感想文という詳細設計に移ってみましょう。これを考えるのが結構面倒だったのですが、AI にテーマを決めてひな形を作ってもらいます。

読書感想文は「山椒魚」にしたいです。 紹介文のテンプレートを書いて。

紹介文のテンプレートを書いて貰います。いわゆる詳細設計ですね。ええ、なんといっても詳細設計です。プログラムの場合はコードを書かないと動かないわけですから、読書感想文は読書感想文自身を書かないと人が書かないといけません。夏休みの宿題は「AI に書かせてはいけない」ことになっているので、ええ、詳細設計にとどめます。

まあ、仕事の場合は「清書の文例」も Copilot に作って貰って、それを手直ししてもいいのですが、中3の課題なので :)

ほかに数学と英語のワークの場合は、全体のページ数を Copilot に伝えて、1チケットで何ページ進めば良いのかを尋ねます。ワークの場合は AI にやって貰うことはできないのですが、英語の訳文はスマホのカメラを使うと便利だったりしますね。げふげふん。

まとめ

読書感想文は寸止めしないと駄目!

カテゴリー: 開発 | 夏休みの計画を AI(Copilot) を使って立てよう はコメントを受け付けていません