
2025.02.18
AIが「嘘のデータ」を返してしまう アルペンが生成AI導入で味わった失敗と、その教訓
リンクをコピー
記事をブックマーク
大嶋勇樹氏:ということで、ここまでで「そもそもアプリケーションアーキテクチャとは何でしょう」という話をしました。ここからが本題的なところで、まず最も基本、最も基本というのは僕の意見ですが、3層アーキテクチャについて話していこうと思います。なにか気になる点があれば、Q&Aに気軽に(質問して)もらえればそちらも回答します。
では、3層アーキテクチャについてに入っていこうと思います。3層アーキテクチャと言われた時に想像するものは、少なくとも私の場合は2つあります。
(スライドを示して)けっこう多くの方がこの2つを思い浮かべるんじゃないかと思います。1つはWebアプリケーションの3層構造と言われるもので、もう1つはアプリケーションの中の3層アーキテクチャというものです。
まずWebアプリケーションの3層構造について、Webアプリケーションは、Webサーバとアプリケーション、アプリケーションサーバと言うこともありますが、Webサーバーとアプリケーションとデータベースの3つから成り立つ3層構造が基本構成と言われています。(スライドを示して)こちらの図に書いている感じですね。
この3層構造を3層アーキテクチャと呼ぶこともあります。どういう役割分担になっているかというと、Webサーバーが固定のHTMLやCSS、JavaScriptを返して、プログラムによる処理が必要だったら、Webサーバーはアプリケーションに依頼します。
アプリケーションは、依頼を受けつけたらプログラムで、HTMLやJSONを生成して返します。データベースはその時に読み書きしたりします。そういった3層構造を3層アーキテクチャということがあります。
(スライドを示して)一方で、アプリケーションの中を3層に分けて整理することがあります。これも3層アーキテクチャと呼ぶことがあります。Webの3層構造でいうところの、真ん中にあるRailsなりLaravelなりSpringなり、なんでもいいですが、そういうアプリケーションの中のコードを3層に分けて整理するようなことがあります。これを3層アーキテクチャと呼ぶこともあります。
ここから3層アーキテクチャと言った時は、Webの3層構造ではなくて、後者のアプリケーションの中を3層に分けた3層アーキテクチャについて話していきます。
(スライドを示して)この3層アーキテクチャですが、プレゼンテーション層、ビジネスロジック層、データアクセス層という3つに分類するものです。
役割を整理してみると、まずプレゼンテーション層はアプリケーションの利用者、アプリケーションの利用者というのは、人間であれば別のプログラムのこともありますが、(その)アプリケーションの利用者とのやりとりをするのが役割です
そしてデータアクセス層は、データベースやファイルといった、データの保存先とやりとりするのが役割です。
ビジネスロジック層は、ビジネスロジックを実装するところです。ビジネスロジックという言葉の意味は後でしっかり説明しようと思うので、まずはプレゼンテーション層と、データアクセス層について、もう少し役割を詳しく見ていこうと思います。
(スライドを示して)データアクセス層は、ファイルやデータベースなど、データを保存するところに対してデータを読み書きするのが役割です。
ビジネスロジックとデータアクセスを分ける、切り離すというのは、保存先がRDBなのか、その他のDBなのか。NoSQLなのか、ファイルなのかわかりませんが、ビジネスロジック層はそれを気にかけないように実装するようなことを言います。
よく見かける方式だと、データアクセス層は「データベースのテーブルと1対1対応した読み書き用のクラスを作るTable Data Gatewayパターン」、Java界隈だと「DAOパターン」と言ったりしますが、こういう実装方式はよく見かけます。
データベースのテーブルに対応したselect、insert、update、deleteみたいなメソッドを持ったクラスを作って、そこにデータベースのテーブルと対応したデータの入れ物クラスとかを受け渡して使うみたいな。そういうのはよく見る実装方式の一種ですね。データアクセス層については、なんとなくイメージがつきやすい気がします。
次にプレゼンテーション層について見てみようと思います。プレゼンテーション層で登場するすごく有名なアーキテクチャがMVC(Model、View、Controller)です。
(スライドを示して)「MVCと3層アーキテクチャはどう対応するんだ」みたいな話がしばしばあると思いますが、それをやってみた図がこんな感じです。3層アーキテクチャは、プレゼンテーション、ビジネスロジック、データアクセスとアプリケーションを分類しています。
MVCはその中でもプレゼンテーション層周辺に注目して、プレゼンテーション層の中をControllerという入力を受けつけたりするものと、見た目、UIを保持するViewに分けています。ビジネスロジックやデータアクセスについては、別途Modelというところに実装しましょうというものです。
ただ、私もいろいろ調べてみたのですが、MVCは歴史の中でどんどん派生形が出てきていて、Modelという概念自体は相当曖昧な感じですね。
なのでMVCといった時、「Controllerという入力を受けつけるところがあって、ViewというUIを担うところがあって、ほかをなんとなくModelと呼んでMVCと言ってしまっている」ということがけっこうあります。
MVCはざっくり「プレゼンテーション層のアーキテクチャですよ」というところを押さえてもらえればいいかなと思います。
「じゃあプレゼンテーション層ってそもそも何?」(ということ)についてもう少しだけ深掘りしようと思います。プレゼンテーション層は、アプリケーションの利用者、利用者は人間だったり別のプログラムのこともありますが、その利用者とやりとりする層です。
(スライドを示して)例えば、以下のようなものがプレゼンテーション層になります。3種類挙げています。1つはいわゆるMVCなどで実装するような、HTMLを返すWebアプリケーションやリクエストを受け取るController、UIを担うViewあたりが、プレゼンテーション層の役割を持っています。
もしJSONなどを返すWebアプリケーション、Web APIみたいなものであれば、APIの受付だったりレスポンスを返したりする出入口のControllerだったり、リクエストとかレスポンスの型がプレゼンテーション層に属します。
ほかにも、例えばコマンドラインアプリみたいなものであれば、コマンド標準入力からのユーザーの入力の受付や、処理結果を標準出力に出すとかはプレゼンテーション層の役割ですね。
よくプレゼンテーション層はフロントエンドのことだと勘違いされることがあるので、ちょっとその点を補足しようと思います。
(スライドを示して)フロントエンドとプレゼンテーション層は別の概念です。フロントエンドはブラウザなど、ユーザーの手元で処理されるものをいいます。Webアプリみたいなものであれば、HTML、CSS、ブラウザ上で動くJavaScriptなどが該当します。モバイルアプリであれば、モバイルアプリを手元にインストールして使うので、フロントエンドと言うこともできます。
一方、サーバーサイド(のプレゼンテーション層)は、通信した先のサーバー上で処理されるもののことを言います。言語としてはRubyやPHP、Java、Python、Go、JavaScriptなどがありますが、いろいろな言語で実装されるところですね。
これまで出してきたプレゼンテーション層、ビジネスロジック層、データアクセス層は、今までの例でいうと、サーバーサイドの中をプレゼンテーション層、ビジネスロジック、データアクセス層に分類できるという話です。
今、サーバーサイドの中と言いましたが、フロントエンドも特に最近はけっこうコード量が多いと思います。フロントエンドの中のコードをこういった3層に分けることも、それはそれでできます。
Webアプリの場合は、フロントエンドをこういう3層アーキテクチャみたいな感じで分けて実装することはあまり聞きませんが、例えばモバイルアプリではわりとそれに近いことをやっている例もけっこう耳にするかなと思います。
この3層に分けるのは別にサーバーサイドに限ったことではなくて、ほかの、特にモバイルアプリでもよく言われる議論ですが、そういうところでも使える話にはなっています。
ちょっと話を戻して、プレゼンテーション層とフロントエンドがなぜややこしいかです。フロントエンドはブラウザなどのユーザーの手元で処理されるもので、プレゼンテーション層は今の例だと、サーバーサイドの中でも一番入口にいるものを指しています。
Webアプリの場合、プレゼンテーション層でHTMLを生成する場合があります。例えばRailsでERBを使った、LaravelでBladeを使った、SpringでThymeleafを使った場合、サーバーサイドでHTMLを生成したりすることになります。そういう時は「このプレゼンテーション層はフロントエンドでもある」と言うこともできるかなとは思います。ブラウザ上で処理されるHTMLを生成しているので、ある意味フロントエンドかなと。
ただ、例えばAPI方式のアプリケーションであれば、プレゼンテーション層には特にHTMLは出てきませんが、ブラウザ上のJavaScriptから通信される。その入口のAPIの口をプレゼンテーション層と呼んだりする。そんな感じですね。ということで「プレゼンテーション層とフロントエンドは別ですよ」というところを補足しました。
(スライドを示して)ということであらためて整理すると、3層アーキテクチャはこういう分担になります。まずプレゼンテーション層にアプリケーションの利用者、人間だったり別のプログラム、これは例えばブラウザ上のJavaScriptから通信してくるとか、どこかにAPIとして公開しておいて関係ないプログラムから通信されるとか、そういうことを想定している。そういう入口の層があります。
もう1つ、データベースやファイルなど、データの保存先とやりとりするデータアクセス層というのがあります。
そして、その間にビジネスロジックを実装するビジネスロジック層があります。これが3層アーキテクチャというもので、アプリケーション設計の中で個人的にこれが一番基本の考え方かなと思っています。
(次回に続く)
関連タグ:
“1つの独立して動く要素”の内部を整理し直す 「改めて整理するアプリケーション設計の基本」で伝えたいこと
アプリケーションアーキテクチャ理解に必要な“3層構造” プレゼンテーション層・ビジネスロジック層・データアクセス層それぞれの役割
3層アーキテクチャで最も謎な「ビジネスロジック層」 “システムのコア”をゲーム「リバーシ」で解説
「ビジネスロジックの処理は2つに分類すると整理しやすい」 4つの例から考える、プレゼンテーション層・データアクセス層の見分け方
ビジネスロジック層内部の2つの実装パターンを比較 選択時に考えたい、アプリケーション設計の観点
「クラスごとの役割を明確化すること」がポイント アプリケーション設計におけるドメインロジックの分離法
重要なのは「基本を押さえ、適したものを採用すること」 “本来の役割”を押さえたアプリケーション設計
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.13
AIを使いこなせない人が直面する本当の課題 元マッキンゼー・赤羽雄二氏が“英語の情報”を追い続ける理由
2025.02.14
報連相ができない部下に対するコミュニケーションの取り方 「部下が悪い」で終わらせない、管理職のスキル向上のポイント
2025.02.12
マネージャーは「プレイング3割」が適切 チームの業績を上げるためのマネジメントと業務の比率
2025.02.13
上司からは丸投げ、部下からはハラスメント扱い、業務は増加…プレイングマネジャーを苦しめる「6つの圧力」とは
2025.02.12
何度言っても変わらない人への指示のポイント 相手が主体的に動き出す“お願い”の仕方
2025.02.13
「みんなで決めたから」を言い訳にして仲良しクラブで終わる組織 インパクトも多様性も両立させるソース原理
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
着想から2か月でローンチ!爆速で新規事業を立ち上げる方法
2025.01.21 - 2025.01.21
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
第20回エクゼクティブメンターイベント「今、「ひと」と組織が共創する〜働き方の未来へ」
2024.12.07 - 2024.12.07