AIの性能を定量化する評価試験のうち「これまでで最も難しい」とされる「人類最後の試験(Humanity's Last Exam)」について、OpenAIのAIエージェント「Deep research」が早くも26.6％という高いスコアを記録したことがわかりました。試験の公開から10日もたたずに最高スコアが183％増加したことになります。
最高でも回答精度9％程度だった「人類最後の試験」でOpenAIのDeep researchが26％以上を記録 - GIGAZINE
⇧ 短期間でスコアが上がったのは驚きなのかもしれないですが、
- 特化型AIで100%の精度を目指す
- 汎用型AIでそこそこの精度を目指す
利用者側としては、「1.特化型AIで100%の精度を目指す」方向で頑張ってもらいたいんですがね...
AIの度重なる「幻覚（ハルシネーション）」によって精神的なストレスが半端ないわけで...
Linuxで検証環境の構築を自動化する場合の初めの一歩は結局シェルスクリプトのファイル（.sh）化になる気がする
ソフトウェアのエンジニアですが、インフラエンジニアの領域の知見が必要になってきて色々と調べているのですが、
⇧ 本職のインフラエンジニアの方から見ても「Ansible」はイケてないと感じるようで安心いたしました。
とは言え、「IaC（Infrastructure as Code）」のツール自体で良いものがほぼ皆無という気はしなくもないので、消去法的に利用せざるを得ないというのが辛い...
選択肢が無いんよね...
で、何だかんだで、Linux環境で検証環境の構築を自動化する初めの一歩は結局シェルスクリプトのファイル（.sh）化になる気がしますと。
と言うよりも、まずは、シェルスクリプトのファイル（.sh）を実行して全ての処理が滞りなく実行される段階にまで、シェルスクリプトを修正する必要があるということですかね。
つまり、
- 認証情報（パスワード）の入力の作業が発生している
- 目視でログの確認作業が発生している
- Ctrl + Cなど人手による作業の介入が発生している
- etc...
⇧ 上記のような人手を介する作業を全て代替する必要がありますと。
このあたりの話が解決できて漸く自動化ツールの選定に入れるような気がしていますと。
ここまでで、早くも疲労困憊といった気分になるのですが...
ちなみに、検証環境の構築作業というと、
⇧ ほとんどが「作業用のサーバー」、所謂「踏み台サーバー」を経由させることが多いと思われるのだが、このあたりはネットワーク周りも絡んでくるのでややこしい...
ちなみに、「Azure」環境で事前に構築済みの「Azure Virtual Machine」に対して「Gitリポジトリ」のソースコードをデプロイするようなテンプレートがあるらしく、
⇧ 上記のissueでscpとかで転送したりできると。
一応、
⇧「Azure 向けの GitHub Actions のマーケットプレース」を検索してみたが、「GitHub Action deployment to azure VM」っぽい「GitHub Actions」は見当たらなかった...
インフラレイヤーとアプリケーションレイヤーとに分けて構築になりそう
で、検証環境の構築をするにしても、
- インフラレイヤー
- アプリケーションレイヤー
で分ける感じにならざるを得ない感じになりそうではある。
昨今、クラウド環境を利用するのがスタンダードになりつつあるので、
| No | 項目 | レイヤー | |
|---|---|---|---|
| インフラ | アプリケーション | ||
| 1 | ネットワーク | ✅ | |
| 2 | ハードウェア | ✅ | |
| 3 | ミドルウェア※1 | ✅ | ✅ |
| 4 | ソフトウェア | ✅ | |
※1 昨今、Dockerコンテナなどでデータベースを稼働させているようなライブラリとかもあるので、「アプリケーションレイヤー」側で用意してるパターンもあり得る。
というような感じで、「レイヤー」によって用意するものが異なってくるわけなのだが、「インフラレイヤー」においては、「クラウドサービスプロバイダー（CSP：Cloud Service Provider）」が提供している「マネージドサービス」を利用することになると思われるので、「Terraform」などを利用して構築することになる気がしていますと。
一方、「アプリケーションレイヤー」においては、「インフラレイヤー」で構築された環境に「ソフトウェア」をデプロイする形になるので「シェルスクリプト」や「Ansible」などを利用する形になる気がしていますと。
最終的には、
- Jenkins
- Cercle CI
- GitHub Actions
などの「継続的インテグレーション/継続的デリバリー（CI/CD：Continuous Integration/Continuous Delivery）」ツールで自動化できるのが理想とは思われるが...
「AI」が良しなに環境構築を自動化する方法を提案してくれれば良いんだが、結局のところ、「幻覚（ハルシネーション）」の頻度が高過ぎるので、まともに機能する状態にもっていくのに、「AI」との嚙み合わないコミュニケーションを幾星霜繰り返す必要があり、途方もない時間はかかってしまいますと...
「AI」との不毛なやり取りが続いて疲弊することが多くて辛い...
まぁ、「システム開発」において「AI」が効果的であるのならば、「自治体システム1700個問題」とかもスパッと解決策を提案してくれると思うんですが、解消されたような話も聞こえてこないですし、依然として「システム開発」の領域において「AI」の恩恵が少ない状況は変わらずという気がしてならない...
『「AI」のおかげで問題が解決しました』っていう人は、その人自身が頑張ったから解決できたんだという気がしてならないんよね...
何となく、
- 期待：AIで解決して欲しい
- 結果：AIで解決できない
のギャップが解消されない状態が解決できる見通しの目途がいつまで経ってもハッキリしないというのが厄介ですな...
そもそも、「システム開発」自体の基本形みたいなのが確立されていないので、「AI」の回答の精度が悪くなるのも致し方ないということですかね...
我々は雰囲気で「システム開発」していると言っても過言ではない状況に置かれているわけですと。
話が脱線しましたが、「IaC（Infrastructure as Code）」は茨の道ですな...
自動化は「言うは易く行うは難し」で、実際に実現するまでが大変過ぎるんよ...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
