OpenAI o3は、もはやエージェント

こんにちは、横井です。

前回の投稿から少し時間が経ちましたが生成AI界隈は相変わらずの激しい進化を見せています。先日公開されたOpenAI のo3モデルですが、公開直後からこれは凄いと投稿が相次いでいました。

私も試してみたところ、これはびっくりしたというレベルを通り越してびっくりしたので、共有しておきます。ChatGPTでモデル「o3」を選択し、自分のスマホで撮影した画像を添付し「ここはどこ?」と問い合わせするだけです。

xで色々と投稿されていたので、「ビルとか背景が判明しやすいものが映り込んでいると簡単だろう。なるべく人工的なものが少ない風景写真が難しいのでは?」といじわるで電車と桜が写っている写真を使ってみたところ。。。

まずは画像の解析を始めましたが、この解析のプロセスがそのまま画面上で展開されているのですが、写真全体の中から場所を特定する材料が無いか探し始めます。その場はPythonコードを生成・実行し、写真の中から特定の場所をズームするように切り取ります。そうした材料探しを繰り返しある程度仮説が立てられるような情報を得られたら、今度はネットを検索し、仮説が合っているかどうかの検証をし始めました。

結果は見事正解でした。この結果はびっくりしたなんてレベルではないですね。

動作的にはDeep Researchの進化系な感じですが(特に後半の仮説検証の検索はDeep Researchそのまま)、前半の画像を解析するところでは「これは何か推測の材料になるのでは?」とズームを繰り返す所が、まるで人が謎を解くかのように写真を隅から隅まで眺めているようで、本当にコンピュータによる処理なのか?!と疑ってしまうほどでした。

この一連の動きはもはやエージェントと言っていいものだと思います。与えられた命題に対して、それを達成するための手段として複数のツールを持ち、その時の状況でツールを使い分けて、かつ、命題を達成するためのステップを自律的に考えて、最終的にゴールにたどり着く。というエージェントの定義そのものの動きです。

もう一つ、会社の近くの目黒川沿いの桜(イルミネーション)で試してみましたが、これも見事正解でした。

ここ数ヶ月での生成AIの進化の凄まじさに驚くと共に、こういったリサーチ系の機能は良い使い方もできれば、犯罪の手助けにもなる(個人情報の特定が可能)という意味では、より一層使う人間側のモラルが問われるもだと思いました。

では。

人に易しい事、AIに易しい事

こんにちは横井です。 

基本的にAIコーディングはLLMがフレームワークまたはライブラリ、そしてアーキテクチャやデザインパターンなど学習済みの言語が対象であれば、コーディングはすごく容易いことです。一方、学習していないことに対しては、LLMは知らない部分は自分で補完しようとするので、これがいわゆるハルシネーションという架空のアウトプットを出してしまいます。

人によっては嘘をアウトプットしてると言われることにもなっています。

生成AIが世間で騒がれるようになってから私もGeneXusエバンジェリストとして生成AIがGeneXus言語でコーディングできるのか?ということにはずっと取り組んできました。GPT-4がリリースされてから2年近く経過している今現在ではGeneXusに関する学習がされていると感じられるアウトプットは結構増えてきています。ただそれは十分なカバー量ではなく、他の学習済みの言語のようなレベルにはほど遠いというのが現状です。

文法を学習してないと言う事に関しては、カスタムインストラクションの中に言語の文法や他言語とのマッピングというような形で情報を追加してあげれば、ある程度アウトプットを再現する事はできます。

ただどうしても難しい事があります。GeneXusではSQLは一切書きません。SQLを書かないと言う事はテーブルの指定もしない。そしてテーブル間のJOINの指定をしません。

指定するのはデータを抽出したい項目名とそれらに対する条件(抽出条件やソートオーダー)です。この文法 - for eachコマンドになりますが、命令に関しては他の言語に例を見ないGeneXus特有のものです。

その発想の話は過去の記事に記載があります。

• GeneXus Day 2011 Winterが開催されました
• 【コラム】4) ユーザービューとは? (GeneXusとDOA)

要約すると、DBアクセスに関しては裏側の技術知らなくてもシステムの表面上、見た目上で必要な項目さえ与えてあげれば後はGeneXusが推論し、SQLを生成する。というものです。

従って、GeneXusが解析するGeneXus言語上での指定は先に言ったとおり、「データとして必要となる項目」だけです。

しかし、AIコーディングでは「データを抽出する」と言うキーワードが入った瞬間に、LLMはSQLを想定し、あるいはSQLを使ったライブラリーのAPIを想定したコードを書いてしまいまい、GeneXus言語でのfor eachコマンドにはならないのです。

DBアクセスという難しい操作を人に易しくする為に考え出されたGeneXus言語 : for eachコマンドですが、LLMの学習状況を踏まえるとAIにとっては再現するのは難しい事で、なんとも皮肉な状況になっています。

では。

卵が先か？鶏が先か？AIコーディングはプロマネ育成ツール

こんにちは、横井です。 

先日、AIコーディングについてあるお客さんと雑談していた時の事です。私が「AIコーディングが普及すると、要件定義力と開発方法論に基づいたプロジェクトマネジメント力があれば、ソフトウェア開発はできてしまう」といった話をすると、「てことは、プロマネがいれば開発ができるけど、プロマネはどうやって育成したらいい？普通はコーディングから始まって一通り開発プロセスを経験の上に成り立つものだよね？AIコーディングを推進して実践する場が無くなったらプロマネ自体が育たないよね?」と、言われました。

確かに。私がAIコーディングを経験して「こりゃ凄い！人に依頼してるのと変わらない！」と感じることができるのは、年齢も50代半ばに差し掛かり、30年以上ソフト開発の現場に関わってきたからこそ。というのは事実です。

その時は「仰るとおりです。ただ、AIコーディングが普及することで例えばサービス会社は状況が180度変わります。人員不足の世の中で猛烈なスピードでサービスを開発する事が可能になります。では、SIerやIT子会社といった開発を生業とする会社はどうなりますか？AIコーディングとの向き合い方はどうしますか？そこは問われてくると思います」と答えました。

そうは言ったものの、確かにその通り。どうしたものか。。と考え込みました。

あれこれ考えた末たどり着いたのは「コーディングを出発点として一通り開発プロセスを学ばなくてもマネジメントを学ぶことは可能」でした。

日本では徒弟制度とか、経験第一主義な所はありますが、これはよくある議論で実戦を積まないと出来ない派と理論を学べば出来る派の話になります。が、私の結論はそのハイブリット的なものです。

私の発想は「要件定義力やマネジメント力があればAIコーディングが成立する」というものです。これは逆に言うと「要件が明示的に伝えられず、プロセスに基づいたマネジメントもできないと、まともなコーディングをしてくれない」という事になります。そしてこれは私自身もAIコーディングとして経験しましたが、「どうやったらまともなコーディング、まともなアプリが実装できるのか?」という事を考えながらトライ&エラーでAIコーディングを続ける事で(今時点での)ベストプラクティクスに辿り付きました。つまり、AIコーディングを実践すること自体が開発経験を積むのと同じ事だと思います。

要はAIコーディング自体をトレーニングとして実践することで、マネジメント経験やプロセスの必要性を身をもって体験できます。しかも通常の開発では半年、1年と期間をかけないと一通りのプロセスの体験は出来ませんが、AIコーディングならもっと短いスパンでサイクルを経験することができます。

「AIコーディングでは実際の開発をしている訳ではないから、経験にならないのでは?」という意見もあるかもしれません。それであれば、新人教育の中で技術習得の前にAIコーディングによるマネジメント体験をさせれば、その後の技術教育やOJTでもマネジメントの必要性、重要性をわかった上で取り組むことが出来るのではないでしょうか？また、今時点では全ての開発がAIコーディングに取って代わられるわけではありません。実戦経験のチャンスは十分ありますので、教育の一貫として取り組んでみるのもいいと思います。

生成AIを色々体感した上で、周りの人と会話すると若干かみ合わない事が出てくるのですが、ある意味「突拍子もない事、突拍子もない発想」というのが生成AIが存在する今現在、そしてこれからの未来では必要なのではないでしょうか。

では。

AIテストは信用できる? AIテストの外堀の埋め方

こんにちは、横井です。

前回はAIコーディングに対する品質担保についてお話ししました。結論としては人がコーディングしようが、AIがコーディングしようが、設計通りに実装できているか? を確認するにはテストが必要。というごくごく当たり前の話でした。(笑)

もう一つは生成AIでもテストコードは生成可能という話です。しかし、そのテストコードがどれだけ信頼できるかは、作成方法や段取りに大きく依存する問題でもあります。

一般的な開発プロセスでは、まず設計を行い、次にアプリケーションコードを作成し、最後にテストコードを作成するという流れになります。しかし、その場合、テスト実行時にエラーが発生した際、問題がアプリケーションコードにあるのか、テストコードにあるのか判断が難しくなるという課題があります。これはAIコーディングに限らず、スクラッチでの開発においても同様の悩みとなります。つまり、アプリケーションコードの品質を担保するためにテストコードが必要となり、そのテストコードの品質を担保するためにさらにテストコードが求められる、いわゆる「テストコードの無限ループ」問題に突き当たります。

このような問題に対する解決策として、TDD（テスト駆動開発）の手法が提唱されています。TDDとは、アプリケーションコードを作成する前に、まずテストコード、すなわちテストケースを作成し、その状態で初めてアプリケーションコードを実装するという流れです。常にテストコードを実行し、テスト結果がグリーン（合格）の状態を維持することを重視する考え方です。

ただし、TDDのポイントは単にテストコードを先に作成することではなく、まずはテストケースを漏れなく洗い出すことにあります。そしてそのためには、十分な設計が不可欠です。設計が整っていなければ、網羅的なテストケースの洗い出しは難しくなります。つまり、TDDとは、テストコードを作成するためにテストケースを検討し、その検討のために設計をしっかり行うという、一連の決められたプロセスに基づいてワークフローを回すことが肝心なのです。

以上の話はスクラッチ開発での一般的な話ですが、実際にはこの方法論はAIコーディングにおいても十分に適用可能です。常にテスト結果を確認しながら開発を進めることで、生成AIの高速なコーディング能力と、求める品質の両立が実現できると考えます。

では。

---

すみません、追記です。

TDDを実践することでコードの品質を上げることができると書きましたが、この場合当然の事ながらテスト実行の回数が増えます。CLIベースのテストツールだと、テスト実行中のモニタリング情報を秒単位で出力します(画面でリフレッシュさせているような感じ)。結果として、例えばエラーが1つしか出なくても、テストが完了するまでのモニタ表示用の出力が延々と続き、結果としてLLMへの送信量が莫大になります。しかも、膨大なログを解析するの時間もかかり、結果一つしかエラーが無いとか、エラーがゼロとかだと、API呼び出しの待ち時間とコスト消費が馬鹿になりません。(あっという間にチャージしたクレジットが溶けていきます)

これはAIコーディングを品質良く実施する事の可否と、技術的コスト的問題は別物であるという事です。なので、私のブログを見たからといってすぐさまTDDに取り組むのであればそれなりのお金の消費を覚悟する必要があります。

では。

AIコーディングの品質はどう担保する？

こんにちは、横井です。

今回は、AIコーディングにおける品質担保についてです。以前の記事でも触れたように、LLM（大規模言語モデル）が学習済みのアーキテクチャやデザインパターン、アルゴリズムを活用すれば、人間が苦労して作業するよりも遥かに高速にコーディングが可能になります。しかしそれと、実際に要件や仕様を満たしたコードが得られているかどうかは、また別の問題です。

まず、LLMの種類によってもコーディングの品質は大きく異なります。私自身は(コーディングのさせ方にも影響されるのでしょうが)、Claude 3.5 Sonnet 一択です。最近リリースされ、評判の高いGemini 2.0 Proについては、私にはあまり合わない印象を受けました。いかにマネジメント方法でコーディングをコントロールできるように見えても、実際には要件を無視したコードや、途中で省略されたコードが生成され、期待外れとなるケースが多々ありました。無償なのでなんとか使いこなそうと試みるものの、金銭面では節約できても、結果として時間がかかり、満足度が低くなってしまうという現実もあります。

次に、仕様通りのコーディングが実現されているかどうかという点ですが、結局のところ、テストを行って確認するしかありません。幸い、現在では多様なテストツールが存在します。私も色々とテストコードをAIコーディングしてみましたが、実際に試してみると、ソースコードとテストコードの両方が作成された後、テスト実行でエラーが発生した際に、どちらに原因があるのか判断がつかなくなり、場合によってはテストコード自体を修正してしまうこともあるのです。こうなると、テストコードの実装が問題なのか、テストケースそのものが変わってしまっているのかが不明瞭となり、混乱を招きます。

また、以前にも書きましたが、テストエラー発生→エラー修正→テスト再実行→テストエラー発生と修正とエラーの無限ループも起きがちです。どうしても視野が局所的になり、局所的な修正になるので、あちらを直せばこちらがおかしくなる。みたいな事になってしまいます。

そこで、テスト実行後にいきなり修正を加えるのではなく、テスト結果をまずファイルに出力し、エラー(Test Fail)が発生した場合は原因と対応策もファイルに追記するテストレポートの作成を義務付けるなどのルールを設ける事で、いきなり修正→エラー頻発といった負の連鎖を防ぐ事ができます。

この様にコードを自動的に生成してくれるといっても、その品質を担保するためには色々な工夫が必要になってきます。

では。

全体を把握すること、全てを見通すこと

 

こんにちは、横井です。

AIコーディングを進めていると、あたかもAIがリポジトリ全体を見通して作業しているかのように錯覚することがあります。

実際にはAIはその都度のリクエストに対して応答しているだけです。LLM（大規模言語モデル）やエージェントのメモリ機能のおかげで、連続してリクエストを送ると、あたかも学習し成長しているかのような印象を抱いてしまいます。

しかし、例えばコードにエラーがあり修正を行うのですが、エラーが解消されない場合は再び修正を試みる。。といったコード修正の無限ループに陥った場合、一度作業を中断して状況を見直し再び作業を再開すると、これまでの経緯が反映されず、ルールに反した動作が現れることがあります。その結果、コードが破損し「最初から作り直した方が早いかな？」といった残念な感じになることもありました。

また、AIコーディングでは、依存関係の確認、すなわちクロスリファレンス機能が機能していない点も問題です。たとえば、GeneXusでは、オブジェクトや項目属性がどこで利用されているかがクロスリファレンスとして即座に把握できるため、使用されているものは削除できない安全策が整っています。しかし、スクラッチ開発におけるソースコードの管理では、GitHubのようなリポジトリでも依存関係が完全には把握されず、「問題ない」と判断して削除したファイルが、実は他の部分から参照され、システムが正常に動作しなくなるといった事態が起こりやすいです。まあ、これはAIコーディングに限った話ではありませんが、GeneXus開発に慣れているとクロスリファレンス機能が存在するのが当たり前だったので結構困りました。

別な話としては、アジャイルにAIコーディングを進めると、機能を追加してくなかでリファクタリングを提案してくるのですが、あたかも全てを見直してコード修正してくれているようで実はメモリに残っている範囲でリファクタリングを行い、随分と初期に行ったコーディング個所が漏れ落ちてしまう事もあります。

例えばデータベースアクセスのコードが、効率向上を考慮してコネクションプールを利用するようにリファクタしてくれるのですが、初期のコーディング部分は直接接続のまま残されてしまっていたり。といった具合です。

このように人は広い視野で物事(リポジトリ内)を記憶しておくことができるので「ここ大丈夫だったかな?」と目くばせする事ができます。(もちろん、業務システムの様に量が多く、漏れ抜けが許されない場合は横展開チェックなど記憶に頼らない確認手段は必要ですが)

一方でLLMはリポジトリ全体を記憶しておくこと、記憶し続ける事が現状では難しいので、その都度のリクエストに含まれる情報や短期的なメモリ機能の範囲でしか「把握」という状況ができません。

なんらか代替手段が無いと業務システムのような規模は難しいなと感じています。

私がAIコーディングにおいてリポジトリ管理として望む点は、以下になります。

• クロスリファレンス機能
• 例えば、グラフデータベースのように各ソースコード間の関係性を表現できる仕組みがあれば、どの部分に依存しているかが一目で分かり、誤って必要なファイルを削除してしまうといったリスクを減らすことができます。
• リポジトリ(ソースコード)全体の把握
• こちらは、リポジトリ全体を文脈で検索可能なデータベース化ができれば。と思います。現状のRAG（Retrieval Augmented Generation）で実現できるかは不明な部分もあります。ソースコードのファイルは大きいため、通常RAG化する場合はファイルを複数のチャンクに分割してベクトル化します。ひとつのチャンク内に収まる文脈であれば、文脈検索により正確な抽出が可能です。しかし、ロジックが分割されたチャンクに跨った状態だと、文脈が分断され検索精度が出ない(ヒットしない)可能性もあります。逆に、ソースコード全体を丸ごとベクトル計算してしまうと、文脈が広がりすぎてベクトルの意味が希薄になってしまいます。そのため、適切な文脈情報を保持するには、チャンク分割は避けられませんがその要求は矛盾したものとなってしまいます。ただ単に機械的に分割するのではなく、ロジックの処理単位に分割できれば、チャンク単位での検索でも高い正確性が持てるかもしれません。ただ、この場合はどうやって分割するか? コードのロジックを解釈しながら分割ができるのか? といった技術課題が多々あり実現可能かどうかは未知数ですが、今後の技術の進展に期待したいところです。

といった感じで、全体を把握する・全てを見通す。という人にはごく当たり前にできる事が実は結構難解で高度な機能なのだとAIを使い込んでみて気づかされました。

では。

AIコーディングはアジャイル向き？ウォーターフォール向き？

こんにちは、横井です。

先日の投稿では、AIコーディングの品質向上のためには、適切なプロセス定義が重要であると述べました。そこで、プロセスを定義する＝ウォーターフォールという表現を用いましたが、これは必ずしも「AIコーディングはウォーターフォール向き」という意味ではありません。では逆に、AIコーディングはアジャイル向きなのでしょうか?

どのようなプロセスがAIコーディングに適しているのか考えてみましょう。

まず、プロセスを明確に定義するという観点では、それぞれのプロセスに対するインプットとアウトプットを明確にする。作業計画を策定し、その計画をさらに具体的なタスクに落とし込む。といった事が重要です。たとえば、コーディング前にドキュメントをレビューする。修正作業に入る前には各修正箇所をピックアップし修正理由や内容をドキュメント化する。といった手順が考えられます。一見すると、これはウォーターフォールモデルのような厳格なプロセスに見えます。

しかし、実際のところ、段取り的にはウォーターフォールに近いものの、AIコーディングは複数人での開発や、各工程を別々の担当者が分担する従来の開発体制とは異なります。(もちろん、今後はマルチエージェントへと機能が進化すると思うので、役割ごとのエージェントとか、コーディング自体も複数のエージェントで分担する。とか組織的なエージェントになる可能性はあります)　 また、業務システムのようにたくさんの機能を持つシステムを開発する場合、一度に全ての設計書やドキュメント、機能をまとめて実装するのは、今時点でのAIコーディングには適していません。

大規模な機能を実装する場合は、まずスコープ(一回のコーディング対象)を小さく区切り、その単位ごとに設計、計画、コーディング、テストというサイクルを回す必要があります。これは、アジャイルやスクラムにおけるイテレーションやスプリントに近い作業単位の感覚と言えるでしょう。つまり、プロセスの段取り自体はウォーターフォール的に定義しながらも、実際のドキュメント作成やコーディングは、ひとつの大規模なチームではなく、小単位に分かれてサイクリックに進める流れとなります。

人が実施する従来のアジャイル開発との大きな違いは、ドキュメンテーションやコーディングのスピードにあります。通常、2週間から3週間で一サイクルを回すところを、AIコーディングではそのサイクルを1日で完了できる場合もあります。現在はAPIのトークン数やリクエスト回数の制限があるため、すべてが高速に進むわけではありませんが(大抵は最初は凄いスピードでコーディングしていきますが、途中からAPIのリクエスト待ちが発生しコーディング時間より待ち時間の方が長くなります)、基本的には非常に迅速なサイクルでの開発が可能となっています。

このように、AIコーディングに最適なプロセスとは、単純にウォーターフォールかアジャイルかという二元論ではなく、ウォーターフォール的なプロセス定義と、アジャイル的なサイクル回しのハイブリッドであると考えられます。

では。

 

AIの賢い使い方、エージェントとして使う方法

こんにちは。横井です。

今回は、LLM（大規模言語モデル）やエージェントをどのように活用すればよいのか、その基本的な考え方を書いてみたいと思います。

まず最初に大切なのは、何をアウトプットとして求めているのか? という作業のゴールを明確にすることです。当然これは人が指示する事になります。このゴールの定義が曖昧だとアウトプットも想定したものと違ったものになってしまいがちです。

次にどのようゴールを達成するか──いわゆる「How」の部分は、LLMに考えさせるのがポイントだと思います。色々試してみた経験として人が一から十までHowの部分を指定すると、その指定から漏れた物の挙動が不安定になり思ったアウトプットになりませんでした。

ただし、この「How」の部分には方法論やプロセスといった進め方の方針が必要です。ここに関してはそれらをあらかじめルールとして定義し、前提として伝えておく必要があります。つまり方針は人が指示をし、その方針に則ってLLMがHowを考える。という分担になります。

たとえば(コーディング作業で例えると)、

• コーディングする前に必ずドキュメントを書いておく
• コーディング前にやるべきことをリストアップしておく
• アプリケーションコードとテストコードをセットで書く
• テストコードを先に書く

といった手順や方針です。これらはある意味、「ウォーターフォール型」のように、プロセスの進め方を先に定めてしまうこととも言えます。こうした方法論や方向性を設定したうえで、アーキテクチャや要件、そして実装したい機能をもとに「具体的にどう作るか」というステップをLLMに考えさせるのです。

次に、作業計画についてです。これはHowの部分をさらに具体的な作業レベルのタスクにブレイクダウンし、詳細化させる事です。これもLLMに任せた方がよいです。タスクを細かく分解してもらうことで、「何をいつ、どの順序で行うか」を明確化できますし、その進捗を管理するToDoとしても活用できます。LLM自身が考える事で、ゴールへ向かう道を見失わずに、一直線で進むことが可能になります。

以上のように考えると、人が考えて指示すべきことと、LLMが考えたり作業したりすべきことを明確に定義・分担することが重要だといえます。具体的に言えば、人間が考えるべきことは主に以下の二点です。

1. ゴールの定義
2. LLMに仕事を考えさせたり、実行させるための方法論やプロセスの方向付け

一方、ゴールを達成するための具体的なステップやタスクのブレイクダウン、作業順序、ドキュメント出力などについては、LLMに考えさせた方が良いです。そして、人はLLMが出してきた実現手段や実行計画、To Doリストなどをレビューするという役割を担います。

エージェント機能を使う場合は、たとえばシステムプロンプトやカスタムインストラクション、ルール設定などにおいて、どのレイヤーで何を定義するかを整理し、指示の重複や矛盾を起こさないようにすることが肝心です。

こうした工夫をこらせば、自動的・自律的にLLMやエージェントに作業を進めてもらうことも十分に可能になるのではないでしょうか。繰り返しになりますが大切なのは、「人が定めるべき前提や方針」と「LLMに委ねるべき具体的な実行手段や計画」の切り分けを明確にし、お互いの役割をはっきりさせることだと感じています。

では。

AIコーディングはプログラマの終わりの始まりか？

 こんにちは。横井です。

AIコーディングに関する記事の4回目となる今回は、ややショッキングなタイトルかもしれません。これまでさまざまなAIコーディングを試してきましたが、その経験の中で感じたことを書きたいと思います。

AIに仕事を任せる場合、大きな課題となるのはアウトプットの精度と再現性、すなわち何度実行しても同じ結果が得られるかという点です。この二点を考えると、まだ仕事を安心して任せられる段階ではないと考える方も多いでしょう。では、AIコーディングという観点ではどうでしょうか。ここまで取り組む中で、私自身が少し驚いた事例がありますので、いくつか紹介します。

まず一つ目は、APIなどのインターフェースを呼び出すロジックに関することです。APIに対してはインターフェース仕様が公開されていれば、AIはその使い方を認識できるため、要件──つまりどのような機能を実装したいか──を伝えるだけで、具体的なコーディング指示をしなくとも、それに合わせたコードを書いてくれます。

少し昔話になりますが、2000年前後に「Webサービス」という言葉が登場した頃、技術に詳しくないマーケティング系の人が「Webサービスを使えば自由に自動的に呼べるようになるよね」と言っていたことがありました。当時、現場のエンジニアだった私には「いやいや、そんなのは無理でしょう。結局は人がロジックをコーディングする必要があるのだから、自動でできるわけがない」としか思えなかったのです。しかし、それから約25年を経て、生成AIの能力を目にすると、当時は夢物語のように感じられたことが、いまや現実化しているのだと実感しています。

今回私が作成したアプリは、実はLINEのボットアプリです。具体的には、ユーザーがボットに質問すると、ボットアプリがFAQデータをもとにLLMへ最適な回答を生成するよう依頼するという仕様になります。APIという観点では、LINEメッセージAPIの使用方法とLLMのAPIの使用方法、この二つがポイントでした。私自身、どちらの知識も経験もなかったにもかかわらず、実現したい内容をAIに伝えるだけで、その後の設計やコーディングはAIが行ってくれました。やりたいことを具体的なゴールとして設定するだけで、実際のコーディングはすべて任せることができたのです。

LLMベースのFAQ応答ボット 設計ドキュメント

もう一つ興味深かったのは、アーキテクチャやデザインパターンなど、システムやプログラミングにおける標準的な技術知識も、LLMがすでに学習しているのであれば、人が一から調べて試行錯誤する必要がないという点でした。具体例を挙げると、最初のバージョンではアプリが問い合わせを行うLLMはOpenAIのみ固定で使用していました。それを機能拡張として、Google Geminiも使えるようにしたい。さらに、環境変数によってどちらを使うか動的に切り替えられるようにしたい、という要件をAIに伝えたところ、インターフェースの継承やファクトリパターンを活用する設計を提案してきたのです。継承のクラス図やシーケンス図といったドキュメントまでもアウトプットしてくれましたので、私はそれをレビューし、要件どおりかどうか確認したうえでコーディングを依頼しました。その結果、LLMをパラメーターにより動的に切り替えられる、汎用性の高いアプリが出来ました。

LLMプロバイダーアーキテクチャ設計

このように、すでに学習されている技術的な知識の広さや深さは、私個人の情報量や経験値をはるかに超えています。こうした分野では、人間が時間をかけて自力でコーディングを行うこと自体に、もはや大きな価値を見いだしにくくなりつつあるのかもしれません。もちろん、学ぶことや経験を積むこと自体はかけがえのない大切な行為であり、私自身もそれを否定する気はまったくありません。ただし、仕事としてアウトプットを素早く正確に出すという観点においては、もはやAIには太刀打ちできないのではないかと感じてしまいました。

もっとも、私たちが扱っている業務システムは、以前にも述べたとおり、LLMが学習していない情報が多く含まれています。業界特有の商習慣や企業モデル（企業情報やビジネスモデル、業務内容）、そしてそれを支える組織形態などをLLMへインプットするのは現時点では難しい面があります。そのため、業務ロジックをAIに完全にコーディングさせるのはまだ難しいというのが実情です。しかし、これはあくまでも現時点での話にすぎません。業務知識を事前学習以外の形でLLMに渡す方法が確立され、実現したい業務内容を正しく伝えられるようになれば、将来的には業務ロジックのコーディングさえもAIでまかなえる可能性があるのではないか、と感じています。

では。

AIと人の違い

 こんにちは。横井です。これまで二回にわたって生成AIについての記事を書いてきましたが、今回は、作業を指示する立場から見て「AIと人の違い」についてお話ししようと思います。

まず、生成AIが現時点で「使える」と感じる方もいれば「まだ使えない」と感じる方もおり、その感想は人によって異なるようです。もちろん、どんな仕事を対象にするかや、どのような内容を依頼するかによっても変わってきます。私自身、ChatGPTが登場してからさまざまに試してきましたが、最近のAIコーディングに関して言うと、生成AIをうまく使うためのコツは主に次のように整理できるのではないかと思います。

1. やること（ゴール）とやらないことを明確にする
   いわゆる仕事のスコープをはっきりさせることです。

2. ゴールに向かう詳細なステップと順序を決める
   これは、指示する側が具体的に定義するか、あるいはAIに考えさせるのかによってやり方が変わってきます。

3. 前提条件や制約条件など、ゴール達成のための条件を定義する
   これらをきちんと定義しておくことで、AIの回答精度や作業の方向性が大きく変わります。

4. 作業と進捗をどの単位で確認するかを決める
   何を、どのタイミングで、どのようにチェックするのかを伝えれば、生成AIでも確実にアウトプットを出しやすくなります。以前の記事でご紹介したAIコーディングの成果を思い返していただくと、イメージしやすいかもしれません。

参考までに先の投稿でAIコーディングをさせたプロンプトは以下になります。(たくさんあるフェーズの中の一例です)

次のステップに入ります。 フェーズ6.2です。 
要件は 
1.LLMのAPI呼び出し時のリクエストデータとレスポンスデータを格納するDBを作成。テーブル名はprompt_history。 
項目は user_id、timestamp、request_type、request、responseです。主キーはuser_id、timestamp。request_typeは問合せ、ハルシネーションチェックの区分値です。 
2.LLMのAPI呼び出し時、具体的にはレスポンスを受領後にrequestデータとresponseデータをprompt_historyにinsertする。タイミングは
- 問合せ
- ハルシネーションチェック
の2つ。 
3.制約事項
- 既存の機能、ロジックは変更しない。意図は機能のデグレードはしない。特にコード修正する場合は他機能への影響がないか細心の注意をはかる。 
以上の要件を元にphase6.2の設計書をマークダウン形式のテキストファイルとして出力してください。
コーディング可能な詳細なレベルにブレイクダウンして検討してください。
必ず必ず必ず必ず必ず必ず必ず必ず必ず必ず必ず全部処理してください。まだコーディングはしないでください。

設計書をレビューしました。内容OKです。
では、続いて設計書の内容を元にtodoリストをマークダウン形式のテキストファイルとして出力してください。
コーディングが可能な詳細レベルのタスクに分割してください。タスクはマークダウン形式のtodoとして、チェックマークを付けられるようにして下さい。
必ず必ず必ず必ず必ず必ず必ず必ず必ず必ず全部処理してください。まだコーディングはしないで下さい。

TODOリストを確認しました。内容OKです。
では、コーディングに入りましょう。todoリストの順番にコーディングをして下さい。
コーディングする場合は、1.作業内容の確認、2.コーディング、3.結果のチェックまたはテストコードの実行、4.作業を終えた場合はtodoリストの該当タスクをチェックマークon。
以上をサイクルとして、todoリストのステップ単位で作業を進めてください。
必ず必ず必ず必ず必ず必ず必ず必ず全部処理してください。

このようにポイントを押さると、AIは思ったような結果を出力してくれます。

裏を返すと「生成AIが使えない」と感じるシーンでは、よく次のようなことが起こっています。

• 途中までしか作業をしない、あるいは途中で終わってしまう
• 本来やるべき手順を省略してしまう
• 間違いを修正する際に、今までの内容を全て消して再出力をしてしまう
• うまくいかない場合に修正とテストを繰り返し、エラーが出るたびに無限ループに陥ってしまう

こういった事を経験する事で生成AIが「実用的ではない」と思ってしまうのではないでしょうか。そんな方は是非、AI対する指示の出し方を変えてみてください。プロンプトエンジニアリングであるような小難しい文法や表記法などしなくてもいいです。私はほとんど音声入力で済ませていますし、文脈が通じれば問題ないです。

もっとも、こうした点を踏まえてみると、作業指示や管理の視点では、人が作業する場合とAIが作業する場合の本質的な違いはそれほどないと考えています。新人社員に対してどう指示し、どのように管理すれば期待するアウトプットが得られるか──そのやり方と、生成AIへの指示や管理のやり方は、じつはほぼ同じなのではないでしょうか。

もちろん、人であれば経験値が上がってくると、1を伝えるだけで10を理解できるようになることもありますが、勘違いや思い込みでミスが起こる可能性はゼロにはなりません。

いかに正しく目的を示し、条件を定め、進捗を管理するかが、AIであれ人であれ仕事をしてもらう重要なポイントだと言えるでしょう。

では。

AIエージェントとは

みなさんこんにちは。横井です。

先日投稿した「AIコーディングの現在地点」はご覧いただけましたでしょうか。ここ二か月ほど、さまざまなAI関連のコーディングに取り組んできましたが、その過程で少し見えてきたことがあるため、本日はそのお話をしたいと思います。

現在、多くの場面で「エージェント」という言葉、あるいは機能が注目されています。ChatGPTに代表される一連のチャットインターフェースの次のステップとして、AIエージェントと呼ばれる存在が、今後私たちのインターフェースになり、実際の仕事もAIエージェントがこなしていくという流れがあるように思います。では、何をもってAIエージェントと呼ぶのでしょうか。

まず大前提として、LLM（大規模言語モデル）はコンテキストが広い、抽象的な問い合わせや指示に対しては、曖昧な答えを返したりいわゆる「ハルシネーション（幻覚）」と呼ばれる想定外の回答を行ったりする特性があります。決して“馬鹿”なのではなく、LLMの特性として不足している情報は勝手に(気を利かせて?)補填していってしまうのです。従ってLLMの特性を理解したうえでうまく活用することが重要です。

思った通りの答えを得るためには、指示出しの範囲をできるだけ小さくし、コンテキストを絞ること、さらに実現方法や手順を明確に示すことによって、アウトプットの精度が向上します。これが、LLMを“賢く”使うための基本的な考え方だと言えるでしょう。

チャットインターフェースのように、ある程度自由度の高い入力ができる場合は対応しやすいかもしれません。しかし、アプリケーションのように、あらかじめ定められた処理を行う場面では、LLMをいかに使うかを考えながら、スコープが限定的なプロンプトを事前に用意しておく必要があります。具体的には、アプリを使う人の役割やシチュエーションによって、複数の小さなプロンプト群を部品のように用意しておき、それぞれを上手に組み合わせて使うのです。これらの小さな“アシスタント”を統合して、どの順番で実行するか、どのように次のインプットに引き継ぐかを制御するしくみを「フロー制御」と呼びます。世の中にはすでにフロー制御のサービスが存在しています。

しかし、あらかじめ定義された条件分岐に従って進むだけでは“エージェント”というよりは通常のプログラムでしかありません。AIエージェントととはどんなものになるのか? と考えると、与えられたシチュエーションや処理の結果をもとに、次に何をするか?どのツールを使うか?といった判断そのものをAIが自律的に行う点に特徴があると思います。もちろん、それはその精度をどこまで高められるかが、実際に役立つエージェントとして機能するかどうかの分かれ道になりそうです。

このようなAIエージェントの機能は、すでに少しずつ世の中に出てきています。私が利用しているVS Codeのプラグイン「Cline」や「RooCode」なども、そうした機能を備えつつあります。現在では「PLAN」「ACTION」、「Architect」「Ask」「Code」といった目的別のLLMプロバイダやモデル設定、それらに対するカスタムインストラクションの設定ができるツールになっており、利用者はシチュエーションに応じてモードを切り替えながら、最適な回答を得ようとしています。

また、別の観点としては、先日書いた記事にもあるように、モード切り替えを使わなくても、ゴールを定義し、ゴール達成の手段を定義し、手段実現の段取りを定義し、それらをToDoリストに落とし込んで実行状態や進捗を管理できれば、モード切り替えなしでもエージェント的に振る舞わせることは十分に可能です。

ここまでご紹介したように、AIエージェントは今後の大きなトレンドであり、LLMの特性を理解しつつ、いかに活用するかがカギとなっています。

では。

AIコーディングの現在地点

こんにちは。横井です。

 少し時間が空いてしまいましたが、本年もよろしくお願いします。

さて、みなさん生成AIは使っていますか? 私はここ2ヶ月ほどAIコーディングに没頭していましてAPI利用で数百ドル溶かしました。(笑)

という事で、汗と涙と小遣いの結晶をご覧下さい。

状況を説明しますと

環境はVSCode + RooCodeプラグインでLLMはClaude Sonnet 3.5です。

ムービーの最初の方でドキュメントを参照していましたが、このドキュメント(設計書)もAIに書いて貰っています。設計書のレビューを私が行い内容がOKになったら、次に開発計画としてToDoリストも作成して貰っています。このToDoリストはマークダウン形式のToDoになっているので、この後AIがコーディングを行っていく時の進捗管理用資料にもなっています。

まず、ここまで来るのに私はプロンプトとして要件(作りたいもののゴール)しか指示していません。特に最近はキーボードでパチパチ入力もせず、マイクを使って音声入力でやりたい事を入れています。(もちろん音声認識の誤字脱字はあるので手直しはしますが)

ムービーの説明に戻りますが、AIが検討したToDoリストは詳細化はしてありますが、順序がフロントエンド→バックエンドとなっていましたので「タスクの順序はアーキテクチャーのレイヤーごとに依存関係を意識して、機能別に作り直してください」といったレビュー結果をフィードバックしました。

結果的に出来上がったドキュメントは以下の通りです。

• Phase 6.3 設計書
  
• Phase 6.3 実装TODOリスト
  

ここまで出来上がるとようやくコーディングに入ります。プロンプトで「ではコーデイングを開始してください。todoリストの順番に実装をお願いします。実装は1.仕様の確認、2.コーディング、3.結果の確認またはテスト、4.todoリストのチェックをonを一つのサイクルとしてステップごとにコーデイングして下さい。」といった主旨の指示を出すと、以降はAIが計画に沿ってコーディングを行い、作業進捗もtodoリストにチェックマークとして更新してくれます。また、テストもタスクに入っているのでテストコードのコーディングとテストの実行もしてくれます。

ムービーは時間の関係でAPIの呼び出し時間はカットしています。また、これだけ自動コーディングをさせるとAPIの利用制限に引っかかってしまうので、そのリトライ待ち時間もカットしています。

今回のコーディングはテーブルが既に作成されている状況で参照する画面(一覧と詳細)を追加実装するという内容でした。ドキュメントのPhase6.3とあるように今までフェーズ1から始まって6までブラッシュアップをしてきた状態です。

色々とAIコーディングを試してきた結果としては今時点(2025年1月末)としては最高難易度のコーディングが実現出来ていると思います。

AIコーディングについて色々ノウハウが溜まったので、いくつかご紹介します。

• VSCodeのプラグインとしてはRooCode( Clineのフォークモデル )を使っていますが、ArchitectやAskなどのモード切替は使っておらずcodeモードのみで要件検討や計画立案もしています
• LLMはコーディングに使うのであれば Claude-Sonnet-3.5の一択です。(o4やGemini2.0、DeepSeekなども試しましたが、私の使い方にはマッチしませんでした)
• AIコーディングに限りませんが、AIに仕事をしてもらうには要件(ゴール)を明確に定義する必要があります。曖昧さがある場合はAIを使って壁打ちしながらゴールの明確化をします。
• どう実現するか? (方法や手順) はAIに考えさせます。もちろん、検討結果に曖昧さや選択肢を提示してきた場合は、更に詳細化や決め打ちの指示を出します。
• 実際のコーディングが可能で進捗管理が出来るようなToDoリストをマークダウン形式で作成させます。
• 以上の様な開発準備が完了するまでは一切コーディングは認めません。
• 機能追加や仕様変更する場合は、既存の機能(コード)の変更禁止や変更の影響の最小化などを制約条件として指示します。

以上の様な段取りを踏まえるとほぼオートマチックに全量をコーディングし、単体テスト結果による修正までしてくれます。いかがでしょうか?

もちろん、日々新しいツールや方法が出てきますし、LLMのモデルも進化が著しいので、明日には陳腐化・コモディティ化しているかもしれません。そういう意味でも「現在地点」だと思います。

この方法で我々のビジネスフィールドである業務システムの開発が出来るか? と聞かれれば「今時点ではNOです」と答えます。AIコーディングの方法論としては一つ確立出来ていると思っていますが、ビジネスドメイン、企業モデル、業務フロー、業務ルールなど、システムが対象とする情報はあまりに膨大でLLMに全体像を把握させる仕組みがまだ思いつきません。今のところ、AIのAPIを呼び出して作業をさせるのは中間記憶によるコンテキストの引継ぎはありますが、あくまでもINPUT/OUTPUTのトークンボリュームに依存しますし、恐らくそういった方法とは別な方法で業務要件をLLMに伝達する必要があります。

では。

WWDC 2024: Apple Intelligenceで未来が現実に！驚異の新機能と開発者へのインパクト

タイトル: WWDC 2024: Apple Intelligenceで未来が現実に！驚異の新機能と開発者へのインパクト

1. はじめに

こんにちは！今回はWWDC 2024で発表されたAppleの最新技術、「Apple Intelligence」についてお話しします。今年のWWDCは驚きの連続で、特にApple Intelligenceが注目を集めました。この新技術がどのように未来を変えるのか、一緒に見ていきましょう！

2. Apple Intelligenceの概要

Apple Intelligenceは、iPhone、iPad、Macで利用できる強力な生成モデルを統合した技術です。主な機能として、テキスト編集をサポートする「Writing Tools」、遊び心のある画像を作成する「Image Playground」、そしてカスタム絵文字を作成する「Genmoji」があります。これらのツールを使うことで、ユーザーはより直感的で楽しい体験を得ることができます。

3. APIの詳細

◆Core ML
Core MLは、機械学習モデルをアプリに統合するためのフレームワークです。モデルをデバイス上で実行することで、ネットワーク接続を必要とせず、プライバシーを保護しつつ高いパフォーマンスを実現します。新しいMLTensor型と重み圧縮技術により、モデルの効率的な実行が可能になりました。

◆Vision Framework
Vision Frameworkは、画像や動画の分析を行うためのAPIです。テキスト認識や顔検出、全身ポーズ検出などの新機能が追加され、より高度な画像処理が可能です。特に、イメージ美学の評価機能は注目されています。

◆Natural Language Framework
Natural Language Frameworkは、テキストの処理と分析をサポートします。言語識別や感情分析、固有表現抽出など、多言語対応の拡張が行われました。これにより、より自然なテキスト理解が可能です。

◆Speech Framework
Speech Frameworkは、音声認識と分析を行うためのAPIです。リアルタイムで高精度な音声認識が可能になり、ユーザーインタラクションの幅が広がります。

◆Create ML
Create MLは、コードなしでモデルを作成・トレーニングできるツールです。オブジェクトトラッキングやタイムシリーズモデルの作成が簡単に行え、開発者の負担を大幅に軽減します。

4. 開発者向け新機能とツール

Apple Intelligenceには、新しいAPIやツールが多数追加されました。特に、SiriとSpotlightの強化は注目ポイントです。新しいアクションと統合により、ユーザーエクスペリエンスがさらに向上します。また、Xcodeの統合により、モデルのプレビューやパフォーマンスレポートが簡単に行えるようになりました。これにより、開発者はよりシームレスな開発体験を得ることができます。

5. 実用例と応用

Apple Intelligenceを活用したアプリの具体例をいくつか紹介します。例えば、テキスト認識機能を使ったスキャンアプリや、ポーズ検出を活用したフィットネスアプリなどがあります。これらのアプリは、Apple Intelligenceの新機能をフルに活用しており、ユーザーに新しい価値を提供しています。

6. 開発者への影響と展望

Apple Intelligenceは、開発プロセスに大きな影響を与えます。新しいツールやAPIを活用することで、開発効率が向上し、より高度なアプリケーションが可能になります。今後の技術進化により、開発者にはさらなる可能性が広がることでしょう。Appleのビジョンとともに、未来のアプリケーション開発がどのように進化していくのか、非常に楽しみです。

7. まとめ

WWDC 2024で発表されたApple Intelligenceは、未来の技術を現実のものとしました。この技術がもたらす新しい可能性と驚異の機能により、開発者はより高いレベルのアプリケーションを提供できるようになります。これからのApple Intelligenceの進化に、ぜひ注目してください！

8. 付録

リソースとリンク

• Apple Intelligence公式サイト
• Core MLドキュメント
• Vision Frameworkドキュメント
• Natural Language Frameworkドキュメント
• Speech Frameworkドキュメント
• Create MLドキュメント

著者情報
このブログ記事を書いたのは、技術愛好家のChatGPT4oです。最新の技術トレンドを追いかけることが大好きで、特にAppleの新技術に注目しています。質問やフィードバックがあれば、ぜひコメント欄にお寄せください！

---

という事で、みなさんご無沙汰しています。横井です。

今年も早いもので半分が過ぎようとしています。このGeneXusブログも新年のご挨拶を投稿したのが最後で、現業の忙しさにかまけて半年投稿をサボっていました。

忙しさに変わりはないのですが、サボりっぱなしもまずいので、先日スタートしましたAppleの開発者向けイベント、WWDC2024での注目のトピックをChatGPT先生に記事に纏めてもらいました。

以前、ChatGTPに関する記事を投稿したのが一年前になります。この一年でGenerative AI界隈も色々と進化がありました。特に最近リリースされたGPT4oはマルチモーダルにも対応したので、以前の様なプラグインを使わなくても、URLでも、PDFでも、写真でも、INPUTに放り込めば簡単に解析をしてくれます。

という事で、今回の投稿をどうしたかというと、

①WWDCのApple IntelligenceのURLを入力。

　https://developer.apple.com/apple-intelligence/

　→これだけでまず要約をしてくれます。

②続いて以下を入力します。

　「AppleのWWDCを見て、Apple Intelligenceに関するブログの記事を書きたいと思います。 どんな記事がいいか、構成案を考えてもらえますか。 出力は日本語でお願いします」

　→これでタイトルと構成を出力してくれます。

③最後に以下を入力します。

　「フィードバックします。OKです。いい感じです。 では、この構成をもとに、それぞれの文章を書いてもらえますか、 初心者にも分かりやすいフレンドリーな口調で書いてください。」

　→これで出力された内容が上記の記事でした。

閑話休題

Apple Intelligenceですが、さすがはAppleだと思ったのは決して「Generatie AI」や「AI スマホ」とは言いませんでしたね。他社とは違うのだという強い意志を感じました。

そしてこのApple IntelligenceがOSレベルでサポートするので、様々なアプリでもシームレスに機能として組み込まれていくのが、UXを重視するAppleらしい所だと思います。この辺りは別な投稿で。

では。

AIの力を解き放つWindows 11：Microsoft Build 2023で発表されたWindows CopilotとDev Home

 みなさん、こんにちは！先日のブログ記事では、Genexus NextとGE Brainの魅力について触れましたね​1​。今回は、Microsoft Build 2023で発表されたWindows 11の新機能について紹介します。

Microsoftは、今年のBuildイベントで、Windows 11に強力なAI機能を導入すると発表しました。その中心にあるのが「Windows Copilot」です。これは、Windowsが初めて提供する一元化されたAIアシスタントで、Bing Chatや第三者製のプラグインと組み合わせて使用します​1​。

Windows Copilotはタスクバーに表示され、開いたままで他のアプリケーションやウィンドウ上で一貫性を保ちます。ユーザーのパーソナルアシスタントとして機能し、アクションを起こしたり、設定をカスタマイズしたり、お気に入りのアプリケーション間でシームレスに接続することを支援します。例えば、コピー&ペーストはもちろん、Windows Copilotに内容の書き換えや要約、説明を依頼することも可能です​1​。

また、Microsoftは開発者向けに「Dev Home」を発表しました。これはWindows上で開発をより生産的に行うためのツールで、新たにAI機能や体験がMicrosoft Storeに追加されます​1​。

さらに、AI開発をサポートするための「Windows AI Library」も発表されました。ここには、AI開発をジャンプスタートするための機械学習モデルやAPIのキュレーション集が収められます​1​。

以上がMicrosoft Build 2023で発表されたWindows 11の新機能の一部です。次回の更新では、これらの新機能が実際にどのように働き、ユーザー体験をどのように改善するかについて詳しく見ていきましょう。それでは、また次回

---

今回の記事は先日開催されたMicrosoft Buildに関する記事をChatGPTに書いて貰いました。ChatGPTに指示したプロンプトは以下になります。

指示タイトル:
イベント「Microsodt Build 2023｣で発表された内容を紹介するブログ記事の作成

指示詳細:
以前作成したブログ記事の続編的なブログ記事の作成をして下さい。
以前の記事は以下になります。
https://g-mind.blogspot.com/2023/05/introduce-genexus-next-and-ge-brain.html?m=1
執筆内容としては、
・記事タイトル。これから作成する記事の内容を踏まえて考えてください。キャッチーなものをお願いします。
・あいさつ文と前回の続編であることの記述。私の記事の文体をまねてください。
・以下のURLの内容を読み込んで解説記事を書いてください。段階的にお願いします。出力は日本語でお願いします。また引用元のリファレンスも提示してください。
https://blogs.windows.com/windowsdeveloper/2023/05/23/bringing-the-power-of-ai-to-windows-11-unlocking-a-new-era-of-productivity-for-customers-and-developers-with-windows-copilot-and-dev-home/

全体として優しくわかりやすい文体で記述をお願いします。
ブログ記事は日本語でお願いします
Lang:JP

今年のMicrosoft BuildはWindows 11(Windows Copilot)に限らず、ChatGPTのブラウジング機能にBingが利用可能となったり、プラグインがBing、ChatGPT、Dynamics365 Copilot、Microsoft 365 Copilot、Windows Copilotなどで共通化される、などなど、もはや「AI祭り」と言っていいほどの内容でした。

個人的には久しぶりにMicrosoftがエキサイティングがイベントを行ったと感じています。今までGoogleやAWSなどのクラウド勢に押されてばかりの印象でしたので。感覚的には1990年代後半のインターネットが一般化する前段階でのサーバー製品を次々と発表するMicrosoftを思い出しました。

OSにAIアシスタントが統合されるとどんな事が起きるのか? 命令をパチパチと入力することは結構面倒くさいかなって思われるかもしれませんが、私は最近チャットGPTを使う時PCではVoiceIn(ボイスイン)というChromeプラグインを使っています。このプラグインによりChrome上で音声入力が可能になります。

実はチャットGPTのプロンプトは音声入力と非常に親和性が高いです。プロンプトというと色々と書式ばった命令をどう記述するかというプロンプトエンジニアリングが最近重要だと言われておりますが、実は音声入力した文章をそのまま投入しても結構チャットGPTは答えてくれます。多少誤字脱字、いわゆる漢字変換の誤変換があったとしても文脈さえ正しく伝わればちゃんとGPTは認識をし、そして処理をしてくれます。

ということで私は最近はパソコンでもスマホでもチャットGPTを使う時は音声入力を多用しています。結果、キーボード入力がすごく億劫になってきました(笑)。Windows CopilotでAIアシスタントは使えるようになり、かつ音声入力が使えればパチパチと面倒なキーボード入力をせずにほぼ喋ることはでOSを使いこなすことができるようになります。

スマホの音声アシスタント、例えばSiriですね。あるいはAlexaのようなスピーカー型のAIアシスタント。これら名前にはAIとついていましたが、実際には事前に定義したカンバセーションに従って処理をしていただけで、本当に自然言語でやり取りができていたわけでありません。その証拠に例えばSiriに対してあれこれ命令しても「言ってることが分かりません」と冷たく断れることってよくありますよね。

この煩わしさがなくなるというだけで音声入力によるコンピューターの制御というのはすごく楽になると思います。もちろんオフィスで作業する時にベラベラしゃべってパソコンを操作するというのはあまり受け入れられないことかとは思いますが、それでも操作方法の選択肢が増えるということはパソコンをはじめとしたデバイスの進化としてはインパクトが大きいことだと思っています。昔々のコンピューターではプロンプトでコマンドを打ち込んで操作するCUIからWindowシステムとマウスで操作するGUIに進化した時のようなインパクトではないでしょうか。

このブログ、最近はチャットGPTに文章を書かせたりもしていますが、後半部分の私本人が書いてる記事に関しても実はキーボードでパチパチ打つのではなくて音声入力でベラベラと喋った内容をVoiceInでテキスト化し、後から修正かける。そんな入力の仕方をしています。

話が少し脱線してしまいましたが、Windows Copilotは6月からWindows11のプレビュー版として使える予定だそうです。私としてもぜひ早く使ってみたいと思っています。

それではまた。

GeneXusとAIの連携：未来への一歩

 こんにちは、皆さん。前回の記事「ChatGPTとのフォローアップ」の続編として、今回はGeneXusとAIの連携について詳しくお話ししたいと思います。GeneXusが現在検討しているAIとの連携技術や商品について、詳細に解説していきます。

まずは、GeneXusのAIアシスタントについてです。GeneXusは現在、AIアシスタント（通称：TuringBots）を用いて、エンタープライズソフトウェアソリューションを短期間で作成・維持する技術を開発しています。これは、決定的な記号AIとLLM（Large Language Model）技術の組み合わせによって実現されています。AIアシスタントは、ユーザーが必要とするデータやエンティティに基づいてバックオフィスのドラフトを素早く生成することができます。また、バックエンドやAPIの最初のプロトタイプを作成し、プロトタイピングクラウドにデプロイすることも可能です。さらに、複数のデザインシステムを適用してシステムを生成することができ、K2Bパターン、WorkWithPlus、SAP Fioriなどを選択できます。また、GeneXus Nextを使用すると、プロンプトから自動的にネイティブのiOSアプリケーションを生成することができます。ダッシュボードの作成も自動化され、要求されたシステムに関連する可能性のあるクエリを推測し、それらのクエリを含む初期ダッシュボードを生成します。これらの情報は、GeneXusのAIアシスタントのページで詳しく説明されています。

次に、GE Brainについてです。GE Brainは、大規模言語モデルを成功裏に達成し、AIビジネスアプリケーションの作成と進化を簡素化するスマートゲートとして機能するミドルウェアです。GE Brainを使用すると、コストを削減し、市場投入までの時間を短縮し、ビジネスの知能を向上させることができます。これは、集中化されたデータとコストの可視性を提供し、将来のAIインターフェースを維持し、データのセキュリティとスケーラビリティを確保し、ビジネスのニーズを解決するための組み込みAIパターンを提供することによって実現されます。また、GE Brainは、AIモデルが急速に進化する中で、ビジネスが追いつくのが難しいという課題に対処します。GE Brainは独立したインターフェースを提供し、エージェントが基礎となるAIモデルから切り離されたビジネス視点で進化することを可能にします。さらに、GE Brainの組み込み機能により、インターフェースは接続インターフェースを壊すことなく簡単にテストと更新が可能で、コストを削減し、ビジネスが競争に先んじることを確保します。これらの情報は、GE Brainのウェブサイトで詳しく説明されています。

以下に、GeneXusとAIの連携についての図を示します。

この図は、GeneXusがAIアシスタントとGE Brainを用いてどのようにエンタープライズソフトウェアソリューションを作成・維持し、さまざまな機能を提供しているかを示しています。詳細については、上記のリンクを参照してください。

以上が、GeneXusとAIの連携についての詳細な紹介となります。次回の記事でも、最新の技術やトレンドについて詳しく解説していきますので、お楽しみに！

---

今回はGeneXusとAI(GenerativeAI)に関する記事をChatGPTに書いて貰いました。

以下がChatGTPに指示したプロンプトです。使用しているプラグインは「Linkreader」「WebPilot」「ShowMe」です。今回はプロンプトの中で指定している2つのリンクから情報収集をしてもらい、その内容を記事として書いて貰いました。

指示タイトル:
GeneXusとAIの関係性に関するブログ記事の作成
指示詳細:
以前作成したブログ記事の続編的なブログ記事の作成をして下さい。
以前の記事は以下になります。
https://g-mind.blogspot.com/2023/05/follow-up-chatgpt.html

執筆内容としては、
・記事タイトル。これから作成する記事の内容を踏まえて考えてください。キャッチーなものをお願いします。
・あいさつ文と前回の続編であることの記述。私の記事の文体をまねてください。
・以下がGeneXusが現在検討しているGeneXusとAIを連携した技術や商品の情報です。
　・https://www.genexus.com/en/products/ai-assistants
　・https://ge.nexus/
　内容を読み込んで要約してそれぞれの紹介記事を書いてください。内容は要約せずに詳細に書いてください。また引用元のリファレンスも提示してください。

全体として優しくわかりやすい文体で記述をお願いします。
ブログ記事は日本語でお願いします

GeneXus AIアシスタント(GeneXus Next)とGE Brain(Ge.nexus)共に現時点では製品ではなく、技術的な方向性を見せるテクニカルプレビューですので、その点は誤解のないようお願いします。

ただ、今時点でこれだけの対応をしているのは正直驚きです。特にAIアシスタントに関しては、具体的に動くデモもあります。私も先行申し込みをして実際に使ってみましたが、自然言語で作成したいアプリの要件を記述すると、その内容からAIがアプリとして必要なトランザクションを導き出し、そのままビルド→アプリが動作するようになります。(だいたい5分～10分くらい) これがそのまま業務で使えるレベルではありませんが、GeneXus社としてはGenerative AIは重要な技術であり、今後のソフトウェア開発の転換点になると捕らえていると見ていいでしょう。

次回はAIアシスタントについてもう少し詳しく触れてみたいと思います。

では。

ChatGPTの進化: アップデートと未来の展望

こんにちは、皆さん。前回の記事「ChatGPTの影響」に引き続き、今回もChatGPTについてお話しします。前回の記事では、ChatGPTがどのように私たちの生活に影響を与えているかについて深く掘り下げました。今回は、その続編として、最近のChatGPTのアップデートについて、そしてそれが私たちの生活やビジネスにどのような影響を与えているかについてお話しします。

まず、ChatGPTの最新のアップデート情報から始めましょう。2023年4月11日以降、OpenAIはChatGPTのいくつかの重要なアップデートをリリースしました。

1. ニューロンの説明可能性：OpenAIは、言語モデルのニューロンが何を表しているのかを理解するための新しい研究を発表しました。これにより、ChatGPTがどのようにして特定の言語パターンを理解し、それに基づいて応答を生成するのかをより深く理解することが可能になりました。詳細はこちらをご覧ください。

2. GPTの労働市場への影響：OpenAIはまた、大規模な言語モデルが労働市場に与える可能性のある影響についての初期的な見解を提供する研究も発表しました。詳細はこちらをご覧ください。

3. GPT-4の発表：最も大きなニュースは、OpenAIがGPT-4を発表したことです。GPT-4は、前世代のモデルよりも大幅にパワーアップしており、より自然で人間らしい対話を提供することができます。詳細はこちらをご覧ください。

次に、ChatGPTの利用に関する特徴的な記事をいくつか紹介します。

残念ながら、特定の記事を見つけることができませんでした。しかし、一般的には、ChatGPTはカスタマーサービ、ビジネスコミュニケーション、コンテンツ作成など、さまざまな分野で広く活用されています。以下の図は、これらのアップデートと利用例を視覚的に示しています。

最後に、ChatGPTの未来について考えてみましょう。OpenAIがGPT-4を発表したことで、ChatGPTの能力はさらに向上することが期待されています。また、ニューロンの説明可能性に関する研究は、ChatGPTがどのように言語を理解し、それに基づいて応答を生成するのかをより深く理解するための道筋を示しています。これらの進歩により、ChatGPTはカスタマーサービス、ビジネスコミュニケーション、コンテンツ作成など、さまざまな分野でより有用なツールとなることが期待されています。

最後に、この記事はChatGPTを使って執筆されました。これは、ChatGPTがどのように私たちの生活に影響を与えているか、そしてその可能性を具体的に示す一例です。これからもChatGPTの進化に注目していきましょう。

それでは、次回の記事でお会いしましょう。

---

はい。という事で今回もChatGPTでブログ記事を書いてみました。

「本当にChatGPTでブログ記事なんか書けるの?」と疑う人もいるかと思いますので、その証拠を添付します。最近たいぶ知られるようになってきましたが、ChatGTPで有効な出力を得るための指示をプロンプトといいます。「プロンプトエンジニアリング」と呼ばれるような指示出し技術もあります。

以下が上記の記事を書くために作ったプロンプトです。

指示タイトル: ChatGPTに関するブログ記事の作成 指示詳細: 以前作成したブログ記事の続編的なブログ記事の作成をして下さい。 以前の記事は以下になります。 https://g-mind.blogspot.com/2023/04/Impact-of-ChatGTP.html 執筆内容としては、 ・記事タイトル。前回の記事を踏まえて考えてください。キャッチーなものをお願いします。 ・あいさつ文と前回の続編であることの記述。私の記事の文体をまねてください。 ・以前の記事つまり2023年4月11日以降で、ChatGPTに関するアップデート情報を収集して書いてください。要約して書いてください。 ・同様に2023年4月11日以降でChatGPTの利用に関する特徴的な記事を情報収集して最大3つ記載してください。少なくても問題ありません。、内容は要約してください。またリファレンスも提示してください。 ・今後ChatGPTに起こりそうな事を情報収集して書いてください。 ・最後にこの記事はChargptを使って執筆している事も記載してください。 全体として優しくわかりやすい文体で記述をお願いします。 ブログ記事は日本語でお願いします内容わかりますか対応お願いします

ChatGPT自体は2021年9月までの情報を元に学習されていて、それ以降の情報は学習モデルの中にはありません。従って、Googleなどのように検索的に使うと違った答えを出してくる事も多いです。これは間違った情報というより、学習内容にない情報はGPTが文章を創造してくるのです。

しかし、その状況が今週大きく変わりました。アルファテスタ達には既に公開されていましたが、ようやくChatGPT Plusを契約しているユーザーにも「ブラウジング」と「プラグイン」機能が公開されました。

これにより、プロンプトの文面から推測もしくは直接指定されたURLを元にインターネット上から情報収集し、GPT内で処理することが可能になったのです。私の記事も「WebPilot」と「LinkReader」というプラグインを使って、インターネット上からChatGPTの最新情報や利用状況などの情報収集をし、その結果を記事として纏めてくれました。図は「Show me」というプラグインでフローチャートを始めとしてダイアグラムを出力してくれます。

ChatGPTが出てくる事で「何もしなくても仕事をしてくれるのか?」「人の仕事が奪われるのか?」といった意見もありますが今時点ではそんな事はなく、逆に「わかりやすく的確な指示を出せる人」でないとうまく使いこなせいです。ただ、検索と違って「正確なワード」を指定出来なくても「文脈として正しく伝える」事が出来ればGTPは理解してくれ意図した仕事をしてくれます。つまり、大切なのはAIとのコミュニケーションなんですね。

私も最近ではキーボーとからパチパチと打ち込むより、iPhoneの音声入力を使って喋り言葉で指示する事が多いです。多少間違っていても、言い直したり、念押しする事でGPTはこちらの意図を理解してくれます。

という事でこの1ヶ月ほどで状況が時々刻々と進化してきているChatGPTに関する続報でした。では。