テストを自動化したり、Dockerfileを書くような作業は一般的に「DevOps（デブオプス）」や「インフラストラクチャー・アズ・コード（Infrastructure as Code, IaC）」の一環と考えられます。また、具体的な目的や内容に応じて以下のような呼称が使われます。

CI/CD（継続的インテグレーションと継続的デリバリー/デプロイ）

テストケースの自動化やDockerfileの設定は、ソフトウェア開発のCI/CDパイプラインを構築する作業の一部です。

Jenkins、GitHub Actions、GitLab CI/CDなどのツールを利用することが一般的です。

Infrastructure as Code (IaC)

Dockerfileを書く行為は、インフラをコードとして管理する「IaC」の一環です。

TerraformやAnsibleと同様に、環境をコードで記述・管理し、自動化する手法に該当します。

自動化エンジニアリング

テストやインフラ構築のプロセスを自動化する活動を包括的に指す言葉です。

SRE（Site Reliability Engineering）

特に運用面での信頼性を高めるために、テスト自動化やインフラ構成を管理する作業を含む場合があります。

それらはかつて自然言語で人間が読むために書かれていたドキュメントをコードで機械が読むように書き換えていく作業だったと解釈できる。2024年現在、LLMの発展によってAIが自然言語を読めるようになった。この後どう変化していくか？

テキストがそのまま機械に理解される時代になると、以下のような変化が予想されます。

コードの役割の変化

これまでは、機械が読むための形式的なコード化が必須だった。

今後は自然言語ベースの仕様や要件から直接コードが生成されるなど、コードは「完成後に見えにくいバックエンド化」していく可能性が高い。

自然言語でのやりとりが中心に

LLMの発展により、要件定義やドキュメント執筆と、コード生成・設定ファイルの更新がシームレスに繋がる。

ビジネスサイドが自然言語で要求を伝え、エンジニアリング部分はLLMが変換・最適化という流れが強まる。

検証・調整の重視

生成されたコードや設定が正しいか、どのように運用・管理するか、という「検証・調整」にエンジニアが注力する。

自動化が進んでも、想定外の挙動や安全性の担保が必要なので、人的な評価・判断がより重要に。

「コード中心」から「対話中心」へのシフト

これまではコードが中心で、ドキュメントが補助的だった。

これからは「LLMとの対話」を通じてドキュメントや要件が生成・更新され、必要に応じてコードをLLMが出力する形へ移行する可能性。

要するに、AIが自然言語のやり取りから技術的タスクを自動生成・自動修正できるようになり、エンジニアは検証・運用・最適化などの「判断力が必要な部分」に集中する流れが強まっていくと考えられます。

厳密な検証を人間が頭でやるのは適切か？形式的検証手法のウェイトが高まるのでは？

自然言語レベルの仕様やコードを人間が目視で厳密に検証するのには限界があります。

LLMがコードや設定を自動生成する時代になるほど、「正しさ」を担保する手法として次のような形式的検証の重要性が高まります。

形式的仕様と証明

TLA+やCoqなど、システム挙動を数学的に証明するフレームワークを使う。

自然言語ベースの抽象的な仕様を、形式化した仕様記述に落とし込むことで検証精度を上げられる。

静的解析ツールの高度化

静的解析ツールがAIと組み合わさり、コードの誤りやセキュリティホールを自動的に検出できる可能性が高まる。

人が見逃しがちな点までチェックできるため、最終的な品質を高めるうえで有効。

人間は抽象化・判断に集中

人間が全てのコード行を頭で確認するより、上記のツールと組み合わせた最終判断・抽象化・運用面での検証に注力する方が効率的。

形式的手法とヒューマンレビューを組み合わせることで、安全性と可用性を両立しやすくなる。

総じて、人間が頭だけで厳密に検証するのは限界があるため、形式的検証の活用度はますます高まると考えられます。

日記2024-12-30←日記2024-12-31→日記2025-01-01

100日前 日記2024-09-22

1年前 日記2023-12-31