アーキテクチャはAI時代をどう生きるか — 関心の分離50年史から考える
Algomatic のテックリードは、AI がコード生成する時代において「関心の分離」の設計価値がむしろ高まるという逆説的な見解を示し、横割りから縦割りへのアーキテクチャ転換を提言している。
キーポイント
関心の分離の本質とAI時代の再定義
Dijkstra が提唱した「人間の認知限界」を助けるための概念だが、現在はLLMのコンテキストウィンドウという新たな認知限界を持つ「二人目の思考者」としての役割が加わった。
設計手法の目的は不変である
AI がコードを書くようになっても、「どこで分けるか」を決める設計プロセスそのものの価値は低下せず、むしろ人間とAIが協調して思考する上で重要になる。
アーキテクチャの進化：横割りから縦割りへ
従来の層（レイヤー）で分ける「横割り」アプローチに対し、機能単位で分ける「縦割り（VSA: Vertical Slice Architecture）」への注目が高まっている。
手段の揺らぎと価値の向上
関心の分離に対する目的自体は変わっていないが、それを達成する具体的な手段として、AI と人間の協働に適した新しいアーキテクチャスタイルが模索されている。
関心の分離の根底にある人間の認知限界
レイヤードアーキテクチャやクリーンアーキなどの手法は、人間が一度に処理できる情報の量に限界があるという制約に基づき、複雑さを局所化して管理しやすくするためのものです。
50 年間の不変の目的と変化する手段
1967 年のカプセル化から 2012 年のクリーンアーキまで、手法や名称は時代とともに変化しましたが、「関心を分離して複雑さを減らす」という根本的な目的は一貫して変わっていません。
AI 時代における新たな認知限界の登場
これまでコードを書く人間の認知限界が制約でしたが、LLM のコンテキストウィンドウという新たな認知限界が存在し、アーキテクチャ設計はこれをどう扱うかが問われています。
影響分析・編集コメントを表示
影響分析
この記事は、AI ツールの普及によってアーキテクチャ設計が不要になるという楽観論（あるいは悲観論）に対し、人間の認知限界と AI の制約を考慮した上で、設計思想そのものの重要性は変わらない、むしろ高度化するべきだという冷静な分析を提供しています。特に「縦割りアーキテクチャ」への言及は、実務現場における具体的な次のステップを示唆しており、テックリード層にとって重要な示唆に富む内容です。
編集コメント
「AI がコードを書く時代＝設計不要」という短絡的な議論に対し、認知科学の観点からアーキテクチャの本質的価値を再評価した良質な考察です。特に LLM のコンテキスト制約と人間側の思考負荷を統合して論じている点が秀逸です。
テックリードの坂本です。
今回 Algomatic では 体制変更 をきっかけに、メンバーそれぞれが好きな技術を好きに語る「技術での自己紹介」を兼ねて、アドベントカレンダーを開催することにいたしました！
本記事は、Algomatic 初夏のアドベントカレンダー 1 日目です 🙌
どんな人が、どんな技術に熱を持って働いているのか、その空気感を社外の方にも知っていただけたら嬉しいです！
1 日目の今回は、AI 時代のアプリアーキテクチャについて、事例を交えて書いてみました。
クリーンアーキテクチャ、ヘキサゴナル、レイヤード、MVC。今までいくつものアーキテクチャを積み上げ、時代によって使い分けてきました。では、AI がコードを書く時代、これらはどうなるのでしょうか。要らなくなるのか、それとも姿を変えるのでしょうか。
そもそも、これらのアーキテクチャは手法も作られた年代もバラバラですが、共通している思想が存在します。それは「関心の分離 (Separation of Concerns)」です。
この言葉を作ったのは、ダイクストラ法 1 で知られる計算機科学者のEdsger Dijkstraです。彼が語っていたのはコードの話ですらなく、「人間の頭は一度に全部を考えられない」という、もっと根本的な問題でした。
しかし、AI でのコーディングが当たり前になり、人間の頭ですべてを意識しなくてよくなった今、この考えはまだ必要なのでしょうか？
本記事の結論から言ってしまうと、私は AI がコードを書くようになっても、「どこで分けるか」を決める「関心の分離」の価値はむしろ上がっていくと考えています。なぜそう感じるのか、ソフトウェアの歴史と一緒に説明させていただきます。
この記事のサマリー
- コードの設計手法は、「関心の分離」と共にあり続けている。MVC からクリーンアーキまで、名前も作られた時代も違うが、目的は人間の有限な認知をどう助けるかという一点だった
- AI の登場で、「関心の分離」の意味が変わった。これまで思考者は人間ひとりだったが、コンテキストウィンドウという認知限界を持つ LLM が「二人目の思考者」として加わった
- 「AI 時代にアーキテクチャはどうあるべきか」はまだ議論されている。
- 揺らいでいるのは「関心の分離」に対する目的ではなく手段。層で切る「横割り」から、機能で切る「縦割り」(VSA) が注目されつつある
- だが本当に大事なのは手段そのものではない。AI が人間とともに思考する時代だからこそ、「どこで分けるか」を決める設計の価値はむしろ上がる
そもそも「関心の分離」とは
関心の分離とは、ざっくり言えば「1 つのコードに複数の役割を詰め込むな。役割ごとに分けて、各部分は 1 つのことだけに責任を持たせろ」という原則です。ここでの「関心 (concern)」は、そのコードが気にしている事柄、つまり入力の検証や業務ルール、データ保存、画面表示などを指します。
言葉だけだとイメージしにくいので、具体例で見てみましょう。「ユーザー登録」を 1 つの関数に全部書くと、こうなります。
async function registerUser(req: Request): Promise<Response> {
}
必ず JSON 形式で返してください。translation フィールドのみ。他のフィールド (technical_terms 等) は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:
{"translation": "翻訳全文"}
極端な例ですが、4 つの関心事が団子になっているので、メール送信の仕様が変わっても DB が変わってもバリデーションが変わっても、毎回この同じ関数を触ることになります。
テストも、DB や送信処理を巻き込まないと書けません。
これを近代的なアーキテクチャのように関心ごとに分けると、こうなります。
- プレゼンテーション層：入力を受け取り、結果を返す (①)
- ドメイン層：業務ルールを判断する (②)
- インフラ層：DB 保存やメール送信など外部とのやり取り (③④)
すると、変更の波及が局所で済み、テストしやすく、差し替えもしやすくなります。レイヤード (Layered) も MVC もクリーンアーキも、根っこはこの「関心事で分ける」です。
そして、これらの嬉しさの大本をたどると、ある一点にたどり着きます。人間が一度に頭の中に置ける量には限界がある、ということだと私は考えています。層が分かれていないコードは、副作用まで含めてすべての影響を同時に認識しないといけませんが、分けてあれば 1 つの要素だけを考えれば済みますし、大胆な変更も関数を取り替えるだけで済みます。
ソフトウェア開発は、関心の分離とともにあった
「一度に一つの側面だけを見ろ」という原則は、ソフトウェア開発においても以下の歴史を辿ってきました。
年
出てきたもの
やってること
1967
オブジェクト / カプセル化 (Encapsulation)
中身を隠して頭から降ろす
1972
情報隠蔽 (Parnas)
"変わりそうなもの"を隠す
1974
関心の分離 (Separation of Concerns, Dijkstra)
一度に一つの側面だけ見る
1979
MVC
表示・入力・データを分ける
2005
ヘキサゴナル (Hexagonal Architecture)
業務ロジックを外界から切る
2012
クリーンアーキ (Clean Architecture)
依存の矢印を全部"内側"に向ける
名前も時代もバラバラですが、クリーンアーキの提唱者 Robert C. Martin（通称 Uncle Bob）自身が 2012 年に、「これらは細部こそ違うが、目的は全部同じ＝関心の分離だ」と話しています。
つまり 50 年間、目的 (関心を分ける) は不変で、手段 (どう割るか) が時代ごとに変わってきただけとも言えるでしょう。そして全部の根っこには、人間の認知は有限であるという制約がありました。
50 年間、その「有限な認知」はコードを書くひとりひとりでした。ですが、もう一人の思考者が来ました。コンテキストウィンドウ (Context Window) という認知限界を持つ LLM です。
これにより「AI が書く時代に、アーキテクチャはどうあるべきか」をめぐり、意見が割れています。
AI こそ綺麗な設計を要求する
雑なコードを AI に食わせると事故ります。ロジックを分離して一貫させておけば、AI は"真のチームメイト"になってくれます。だから規律は今まで以上に必要になる、という立場です。
人間に綺麗な設計は、AI には分かりにくい
従来のクリーンアーキは層ごとにディレクトリを切るので、1 機能を直すのに controller / service / repository / domain と何箇所も見て回ることになります。LLM には特にキツくて、コンテキストに詰める情報が増えるほど焦点がぼやけるからです。だから「コンテキストの最小化」と「純粋関数の最大化」へ寄せるべきだ、という立場です。
では、どちらが正しいのでしょうか。結論から言うと、まだ答えは出ていません。
それを象徴するのが、開発者の生産性を測った METR の実験です。2025 年前半、ベテラン OSS 開発者に AI を使わせたところ、むしろ 19% 遅くなりました。しかも本人たちは事前に「24% 速くなる」と予想し、終わった後も「20% 速かった」と感じていた。知覚と実測が真逆だったのです。(2026 年 2 月の追試では一部で反転しており、まさに動いている最中の話です。)
ただ、どの設計が正解かは各自考えが違っても、「設計そのものの重要度が上がった」点では見解が揃っています。
それゆえに、揺らいでいるのは目的ではなく手段のほうです。これまでは人間の認知に合わせて「レイヤーで横に割る」のが基本でした。それが今、AI のコンテキスト局所性に合わせて、機能ごとに 1 箇所へ閉じる「縦割り」へと引き直されつつあります。
バーティカルスライスアーキテクチャという選択肢
この「縦割り」には名前があります。バーティカルスライスアーキテクチャ (VSA) と呼ばれています。提唱は Jimmy Bogard、2018 年です(MediatR の作者でもあります)。ここでも歴史は繰り返していて、命名は 2018 年でも、彼は 2015 年には同じ趣旨を語っていました。
発想はシンプルで、技術的な役割 (層) で切るのをやめて、機能 (ユースケース) で切るというものです。先ほどの registerUser で考えてみましょう。層で切る (横に割る) とこうなります。
src/
├── presentation/userController.ts ← 入口
├── application/registerUserService.ts ← ロジック
├── domain/user.ts ← ルール
└── infrastructure/userRepository.ts ← 保存
1 機能を直すのに 4 フォルダを行き来します。VSA(縦に割る) だとこうです。
src/features/
├── registration/ ← 登録に必要なものが全部ここ
│ ├── registerUser.ts （入口・ロジック・結線）
│ ├── registrationRules.ts （純粋関数の業務ルール）
│ └── registration.test.ts （この機能のテスト）
└── login/ ← ログインは別スライス
1 機能 = 1 フォルダ。registration/ を開けば関わるものが全部そこにあります。
これが AI 時代に効くと考える理由は 2 つです。
ひとつはコンテキストの局所性（文脈の局所的性質）。「登録まわりを直して」と頼むとき、渡すべき文脈が registration/ に閉じていて、4 箇所に散らばっていません。LLM の認知限界に、フォルダ構造のほうを合わせにいく方向です。
もうひとつは構造が仕様になること。features/ の一覧が、そのままシステムができることの一覧になり、人間にも AI にも地図になります。
しかし、VSA は万能薬ではなく、私たちのチームもまだまだ移行できていません。トレードオフははっきりしていて、スライス間でコードが重複しやすく、エラー処理やログのような横断的関心事（クロスカッティング・コンサーン）の一貫性には意識的な設計が要ります。
規範がゆるいぶん、ジュニア中心のチームでは「Controller は Service を呼ぶ」式のクリーンアーキのほうが秩序を保ちやすい、という指摘もあります。
「AI 時代だから縦割りが正解」と断言できるデータも、まだありません。海外でもクリーンアーキと VSA を同じ API で実装して比べる、といった検証がようやく 2026 年に出始めた段階です。METR と同じで、これは動いている最中の問いです。
Algomatic は、より良い設計を日々試し続けています
Algomatic では、AI というもう一人の思考者の制約に合わせて、「どこで切るか」をもう一度考え直す時期に来ていると考え、いままさに試しているところです。VSA のデメリットについても、横断的関心事のような繰り返し現れるパターンの設計を AI に任せられれば、弱点はむしろ「二人目の思考者」と分担できる領域になるかもしれません。そう考えながら、実際に手を動かして検証しています。
おわりに
縦割りが正解かどうかは、実のところ本質ではありません。この 50 年、設計の手法は何度も書き換えられてきましたが、「どこで関心を分けるか」を考える営みそのものは、一度も古びていません。むしろ、コードを書く作業を AI に手放せるようになったぶん、人間に残るのは「どこで分けるか」という関心の分離、その設計判断そのものです。
関心の分離は死なない。むしろ、これからは人間と AI のあいだにも引かれていくものだと思います。AI が書く時代にこそ、その価値は濃くなっていくはずです。
エンジニアを募集しています！
Algomatic では、「AI 革命で人々を幸せにする」をミッションに、変化の速い領域でも 学びや試行錯誤を続けられる エンジニアを募集しています。
もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！
参考文献
- Matt Webb, "An appreciation for (technical) architecture" (Interconnected, 2026 年 3 月) — https://interconnected.org/home/2026/03/28/architecture
- METR、「2025 年初頭の AI が熟練オープンソース開発者の生産性に与える影響の測定」(2025 年 7 月) — https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- METR、「開発者生産性実験の設計を変更します」(2026 年 2 月、追試に関する続報) — https://metr.org/blog/2026-02-24-uplift-update/
- ロバート・C・マーティン、「クリーンアーキテクチャ」(The Clean Code Blog, 2012 年 8 月) — https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
- ジミー・ボガード、「垂直スライスアーキテクチャ」(2018 年) — https://www.jimmybogard.com/vertical-slice-architecture/
- ディクストラ、「科学的思想の役割について」(EWD447, 1974 年) — https://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD447.html
原文を表示
テックリードの坂本です。
今回Algomaticでは 体制変更 をきっかけに、メンバーそれぞれが好きな技術を好きに語る 「技術での自己紹介」 を兼ねて、アドベントカレンダーを開催することにいたしました！
本記事は、Algomatic 初夏のアドベントカレンダー1日目です 🙌
どんな人が、どんな技術に熱を持って働いているのか、その空気感を社外の方にも知っていただけたら嬉しいです！
1日目の今回は、AI 時代のアプリアーキテクチャについて、事例を交えて書いてみました。
クリーンアーキテクチャ、ヘキサゴナル、レイヤード、MVC。今までいくつものアーキテクチャを積み上げ、時代によって使い分けてきました。では、AI がコードを書く時代、これらはどうなるのでしょうか。要らなくなるのか、それとも姿を変えるのでしょうか。
そもそも、これらのアーキテクチャは手法も作られた年代もバラバラですが、共通している思想が存在します。それは「関心の分離(Separation of Concerns)」です。
この言葉を作ったのは、ダイクストラ法1で知られる計算機科学者のEdsger Dijkstraです。彼が語っていたのはコードの話ですらなく、「人間の頭は一度に全部を考えられない」という、もっと根本的な問題でした。
しかし、AI でのコーディングが当たり前になり、人間の頭ですべてを意識しなくてよくなった今、この考えはまだ必要なのでしょうか?
本記事の結論から言ってしまうと、私は AI がコードを書くようになっても、「どこで分けるか」を決める「関心の分離」の価値はむしろ上がっていくと考えています。なぜそう感じるのか、ソフトウェアの歴史と一緒に説明させていただきます。
この記事のサマリー
- コードの設計手法は、「関心の分離」と共にあり続けている。MVC からクリーンアーキまで、名前も作られた時代も違うが、目的は人間の有限な認知をどう助けるかという一点だった
- AI の登場で、「関心の分離」の意味が変わった。これまで思考者は人間ひとりだったが、コンテキストウィンドウという認知限界を持つ LLM が「二人目の思考者」として加わった
- 「AI 時代にアーキテクチャはどうあるべきか」はまだ議論されている。
- 揺らいでいるのは「関心の分離」に対する目的ではなく手段。層で切る「横割り」から、機能で切る「縦割り」(VSA)が注目されつつある
- だが本当に大事なのは手段そのものではない。AIが人間とともに思考する時代だからこそ、「どこで分けるか」を決める設計の価値はむしろ上がる
そもそも「関心の分離」とは
関心の分離とは、ざっくり言えば「1つのコードに複数の役割を詰め込むな。役割ごとに分けて、各部分は1つのことだけに責任を持たせろ」という原則です。ここでの「関心(concern)」は、そのコードが気にしている事柄、つまり入力の検証や業務ルール、データ保存、画面表示などを指します。
言葉だけだとイメージしにくいので、具体例で見てみましょう。「ユーザー登録」を1つの関数に全部書くと、こうなります。
async function registerUser(req: Request): Promise<Response> {
}
極端な例ですが、4つの関心事が団子になっているので、メール送信の仕様が変わってもDBが変わってもバリデーションが変わっても、毎回この同じ関数を触ることになります。
テストも、DBや送信処理を巻き込まないと書けません。
これを近代的なアーキテクチャのように関心ごとに分けると、こうなります。
- プレゼンテーション層：入力を受け取り、結果を返す(①)
- ドメイン層：業務ルールを判断する(②)
- インフラ層：DB保存やメール送信など外部とのやり取り(③④)
すると、変更の波及が局所で済み、テストしやすく、差し替えもしやすくなります。レイヤードも MVC もクリーンアーキも、根っこはこの「関心事で分ける」です。
そして、これらの嬉しさの大本をたどると、ある一点にたどり着きます。人間が一度に頭の中に置ける量には限界がある、ということだと私は考えています。層が分かれていないコードは、副作用まで含めてすべての影響を同時に認識しないといけませんが、分けてあれば1つの要素だけを考えれば済みますし、大胆な変更も関数を取り替えるだけで済みます。
ソフトウェア開発は、関心の分離とともにあった
「一度に一つの側面だけを見ろ」という原則は、ソフトウェア開発においても以下の歴史を辿ってきました。
年
出てきたもの
やってること
1967
オブジェクト / カプセル化
中身を隠して頭から降ろす
1972
情報隠蔽 (Parnas)
"変わりそうなもの"を隠す
1974
関心の分離 (Dijkstra)
一度に一つの側面だけ見る
1979
MVC
表示・入力・データを分ける
2005
ヘキサゴナル
業務ロジックを外界から切る
2012
クリーンアーキ
依存の矢印を全部"内側"に向ける
名前も時代もバラバラですが、クリーンアーキの提唱者 Robert C. Martin（通称 Uncle Bob）自身が 2012年に、「これらは細部こそ違うが、目的は全部同じ＝関心の分離だ」と話しています。
つまり50年間、目的(関心を分ける)は不変で、手段(どう割るか)が時代ごとに変わってきただけとも言えるでしょう。そして全部の根っこには、人間の認知は有限であるという制約がありました。
50年間、その「有限な認知」はコードを書くひとりひとりでした。ですが、もう一人の思考者が来ました。コンテキストウィンドウという認知限界を持つ LLM です。
これにより「AI が書く時代に、アーキテクチャはどうあるべきか」をめぐり、意見が割れています。
AI こそ綺麗な設計を要求する
雑なコードを AI に食わせると事故ります。ロジックを分離して一貫させておけば、AI は"真のチームメイト"になってくれます。だから規律は今まで以上に必要になる、という立場です。
人間に綺麗な設計は、AI には分かりにくい
従来のクリーンアーキは層ごとにディレクトリを切るので、1機能を直すのに controller / service / repository / domain と何箇所も見て回ることになります。LLM には特にキツくて、コンテキストに詰める情報が増えるほど焦点がぼやけるからです。だから「コンテキストの最小化」と「純粋関数の最大化」へ寄せるべきだ、という立場です。
では、どちらが正しいのでしょうか。結論から言うと、まだ答えは出ていません。
それを象徴するのが、開発者の生産性を測ったMETR の実験です。2025年前半、ベテラン OSS 開発者に AI を使わせたところ、むしろ 19% 遅くなりました。しかも本人たちは事前に「24% 速くなる」と予想し、終わった後も「20% 速かった」と感じていた。知覚と実測が真逆だったのです。(2026年2月の追試では一部で反転しており、まさに動いている最中の話です。)
ただ、どの設計が正解かは各自考えが違っても、「設計そのものの重要度が上がった」点では見解が揃っています。
それゆえに、揺らいでいるのは目的ではなく手段のほうです。これまでは人間の認知に合わせて「レイヤーで横に割る」のが基本でした。それが今、AI のコンテキスト局所性に合わせて、機能ごとに1箇所へ閉じる「縦割り」へと引き直されつつあります。
バーティカルスライスアーキテクチャという選択肢
この「縦割り」には名前があります。バーティカルスライスアーキテクチャ(VSA) と呼ばれています。提唱は Jimmy Bogard、2018年です(MediatR の作者でもあります)。ここでも歴史は繰り返していて、命名は2018年でも、彼は2015年には同じ趣旨を語っていました。
発想はシンプルで、技術的な役割(層)で切るのをやめて、機能(ユースケース)で切るというものです。先ほどの registerUser で考えてみましょう。層で切る(横に割る)とこうなります。
src/
├── presentation/userController.ts ← 入口
├── application/registerUserService.ts ← ロジック
├── domain/user.ts ← ルール
└── infrastructure/userRepository.ts ← 保存1機能を直すのに4フォルダを行き来します。VSA(縦に割る) だとこうです。
src/features/
├── registration/ ← 登録に必要なものが全部ここ
│ ├── registerUser.ts （入口・ロジック・結線）
│ ├── registrationRules.ts （純粋関数の業務ルール）
│ └── registration.test.ts （この機能のテスト）
└── login/ ← ログインは別スライス1機能 = 1フォルダ。registration/ を開けば関わるものが全部そこにあります。
これが AI 時代に効くと考える理由は2つです。
ひとつはコンテキストの局所性。「登録まわりを直して」と頼むとき、渡すべき文脈が registration/ に閉じていて、4箇所に散らばっていません。LLM の認知限界に、フォルダ構造のほうを合わせにいく方向です。
もうひとつは構造が仕様になること。features/ の一覧が、そのままシステムができることの一覧になり、人間にも AI にも地図になります。
しかし、VSA は万能薬ではなく、私たちのチームもまだまだ移行できていません。トレードオフははっきりしていて、スライス間でコードが重複しやすく、エラー処理やログのような横断的関心事の一貫性には意識的な設計が要ります。
規範がゆるいぶん、ジュニア中心のチームでは「ControllerはServiceを呼ぶ」式のクリーンアーキのほうが秩序を保ちやすい、という指摘もあります。
「AI 時代だから縦割りが正解」と断言できるデータも、まだありません。海外でもクリーンアーキと VSA を同じ API で実装して比べる、といった検証がようやく 2026年に出始めた段階です。METR と同じで、これは動いている最中の問いです。
Algomatic は、より良い設計を日々試し続けています
Algomaticでは、AI というもう一人の思考者の制約に合わせて、「どこで切るか」をもう一度考え直す時期に来ていると考え、いままさに試しているところです。VSA のデメリットについても、横断的関心事のような繰り返し現れるパターンの設計を AI に任せられれば、弱点はむしろ「二人目の思考者」と分担できる領域になるかもしれません。そう考えながら、実際に手を動かして検証しています。
おわりに
縦割りが正解かどうかは、実のところ本質ではありません。この 50 年、設計の手法は何度も書き換えられてきましたが、「どこで関心を分けるか」を考える営みそのものは、一度も古びていません。むしろ、コードを書く作業を AI に手放せるようになったぶん、人間に残るのは「どこで分けるか」という関心の分離、その設計判断そのものです。
関心の分離は死なない。むしろ、これからは人間とAIのあいだにも引かれていくものだと思います。AI が書く時代にこそ、その価値は濃くなっていくはずです。
エンジニアを募集しています！
Algomatic では、「AI革命で人々を幸せにする」をミッションに、変化の速い領域でも 学びや試行錯誤を続けられる エンジニアを募集しています。
もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！
参考文献
- Matt Webb, "An appreciation for (technical) architecture" (Interconnected, 2026年3月) — https://interconnected.org/home/2026/03/28/architecture
- METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" (2025年7月) — https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- METR, "We are Changing our Developer Productivity Experiment Design" (2026年2月、追試に関する続報) — https://metr.org/blog/2026-02-24-uplift-update/
- Robert C. Martin, "The Clean Architecture" (The Clean Code Blog, 2012年8月) — https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
- Jimmy Bogard, "Vertical Slice Architecture" (2018年) — https://www.jimmybogard.com/vertical-slice-architecture/
- Dijkstra, "On the role of scientific thought" (EWD447, 1974年) — https://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD447.html
関連記事
[AINews] 今日特に大きな出来事はありませんでした
Latent Space は、GLM 5.2 が依然として注目されていると指摘しつつ、AIE WF 2026 の通常チケットが月曜日に完売すると発表しました。同サイト購読者向けに限定割引を提供し、参加者には Warp や Datadog などからのスポンサークレジットも付与されます。
米国がアンソロピックの「Fable 5」発売を禁止、しかし市場は動じず
米国政府は国家安全保障上の懸念から、アマゾンの研究者らがガードレール回避手法を発見したとして、アンソロピックに対し最新モデル「Fable 5」と「Mythos 5」の販売差し止めを命じた。サイバーセキュリティ研究者らはこの措置が危険だとする公開書簡に署名し、同社も他モデルでも同様の抜け道が存在すると指摘している。
社内データ分析エージェントの構築方法について
GitHub は、大規模なデータ組織が直面する自己完結型のデータアクセスと洞察提供の課題に対し、AI を活用した信頼性の高い解決策として、社内でデータ分析エージェントを構築したことを発表した。
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み