はじめに – 勉強会、危うし

なんと、主催者である私が出向になりました。

開催できないかと思われたそのとき、ひらめきました。

「人に頼もう」

ということで、なんとか1ヶ月坊主を回避しました。

数ヶ月後にはまた私が主催の座を奪います。

そして、1週間で内容をまとめて投稿するという目標が早くも瓦解しました。
ここは強がらずに「中旬公開」に変更します。

今回の発表内容

MVCモデルについて
インターネット・プロトコルについて：マスタリングTCP/IP
AIスライド生成ツールの進捗
Antigravityについて
今回の反省

MVCモデルについて

発表者：L.Gさん

最近バックエンドについて勉強しているので、今回は「MVC(Model View Controller)」についてお話します。

レストランに例えてMVCを解説します。

全体の流れ

客(User)がメニュー(View)を見て料理を注文する
↓
ウェイター(Controller)が注文をシェフ(Model) に伝える
↓
シェフ(Model)が冷蔵庫(DB)から食材を取り出して料理を作る
↓
シェフ(Model)が完成した料理をウェイター(Controller)に渡す
↓
ウェイター(Controller)が客(User)に料理を渡す

実際には以下のような流れです。

UserがViewを操作する
↓
Controllerがリクエストを解釈したりエラーハンドリングをしたりしてModelを呼び出す
↓
ModelがDBから値を取得して返却する
↓
Controllerが値とViewを返却する
↓
UserがViewを閲覧する

このように、各工程が役割分担されています。

なぜ役割を分けるのか

どこかひとつでも欠けるとどうなるでしょうか。

例えば、メニューを無くすと客は何が注文できるのか分からず、何もできません。
同様に、ViewがなければUserはアプリケーションを操作できないでしょう。

例えば、ウェイターがいないとシェフが直接注文を取らなければならず、調理中は注文が取れなかったり料理の提供がスムーズに行えなかったりします。
同様に、ControllerがなければModelはUserからリクエストを処理して返答しなければならず、処理が複雑になるでしょう。

例えば、シェフがいないと料理を作れる人がいないため何も提供できません。
同様に、ModelがないとControllerがリクエストの解釈とデータの取得とレスポンスの送付を行わなければならず、処理が複雑になるでしょう。

例えば、メニューもウェイターもシェフもいないと、客は自分で冷蔵庫を開けることができてしまいます。
同様に、Userが直接DBにアクセスできるようなことがあってはなりません。

MVCの利点

アプリケーションの見た目、処理、データの取り扱いを分けることで、それぞれの役割に余計な動きが発生しないようになっています。
例えば、Controllerを介すことでModelはデータを取得する前にバリデーションチェックを行わずに済みます。

また、Model、View、Controllerのいずれかを修正しなければならなくても、他への影響を減らすことができます。
これは「関心の分離」という考え方です。

MVCを採用することでアプリの処理の構造がわかりやすくなり、アプリを作りやすくなります。

インターネット・プロトコルについて：マスタリングTCP/IP

発表者：N.Aさん

今回の内容は「マスタリングTCP/IP 入門編第6版」第4章 IP(Internet Protocol) 1節〜5節を掻い摘んでいます。
何も知らなくても読めますが、基本情報技術者試験のテクノロジ分野の知識があるとよりよく理解できるでしょう。
(札幌本社にあります)

TCP/IPは4つの層で定義されています。

4層：アプリケーション層
3層：トランスポート層
2層：インターネット層
1層：ネットワークインターフェイス層

IPはインターネット層のプロトコルです。
TCP/IPの心臓部ともいえるインターネット層は

IP(Internet Protocol)
ICMP(Internet Control Message Protocol)

から構成されています。

OSI参照モデルと対応付けられるTCP/IPですが、OSI参照モデルが概念的なものでネットワークの仕組みを理解するためのものであることに対して、TCP/IPは実装をベースとして作られており実際にインターネットで使われるプロトコル群です。

IPの役割

IPはOSI参照モデルでは第3層にあたります。
終点ノード間の通信を実現する役割があり、具体的には端末などの通信を実現します。

ネットワーク層とデータリンク層はそれぞれ機器同士の通信を提供します。
ネットワーク層は物理的に接続されていないネットワーク間での通信を、データリンク層は物理的に接続された機器同士の通信を提供します。
列車の旅行で例えると、データリンク層は駅から駅への切符で、ネットワーク層は旅行の行程表です。

IPには3つの大きな役割があります。

IPアドレス
終点ホストまでのパケット配送(ルーティング)
IPパケットの分割処理と再構築処理

IPアドレス

IPアドレスは32ビットの正整数値で表され、「ネットワーク部」と「ホスト部」に別れます。
例:)10101100.00010100.00000001.00000001(2進数)、172.20.1.1(10進数)
IPアドレスにつけられる「/24」などの表記は、ネットワーク部の先頭からのビット数を表します。この場合は先頭から24ビットがネットワーク部です。

IPアドレスは4つのクラスに分類されていました。
先頭から4ビットまでのビット列の組み合わせでネットワーク部とホスト部を決めていました。
クラスAからDまであり、順に先頭から8ビット、16ビット、24ビット、32ビットをネットワーク部にしていました。

クラスのしくみでは利用できるIPアドレスの数に無駄が多くなってしまいます。無駄を少なくするためにIPアドレスと併記されるサブネットマスクという仕組みが導入されました。
IPアドレスと同じく32ビットの正整数値で表され、2ビットで表記したときに「1」のビットがネットワーク部になります。

ルーティング

IPアドレスのみでは宛先に届けることはできません。送りたい宛先に届けられるルータやホストの情報が必要です。
ルーターから終端への経路の制御を「ルーティング」とよびます。
ルーティングには手動設定のスタティックリーティング(静的経路制御)と自動設定のダイナミックルーティング(動的経路制御)があります。
ダイナミックルーティングはルーター同士が自動で情報交換できるようにルーティングプロトコルを設定する必要があります。

ルーターはいくつかのルーティングを束ねることができます。
例えばルーターに複数のIPアドレスが当てられている場合、別のルーターがルートを集約できます。
すべての住宅が直接郵便物を受け取るのではなく、各地域ごとに郵便局を設置して地域単位で郵便物を扱うようなイメージです。
ルーターAが192.168.3.0/26、192.168.3.64/26、192.168.3.128/26のIPアドレスが当てられている場合、ルーターBが192.168.3.0/24宛の通信をすべて受け取ってからルーターAに振り分けることができます。
これによって経路の候補が縮小されリソースに余裕ができます。

分割処理と再構築処理

データリンクによってデータの最大転送単位(MTU)は異なります。
IPはデータリンクの上位層であり、最大転送単位に左右されることなく利用できなければなりません。
データリンクはそれぞれの目的に合った最大転送単位が決められています。

ホストやルーターは必要に応じてデータの分割処理をします。
例えば、ホストからルーターへ9000のデータが送られたとき、その先にイーサネットの最大転送単位は1500であるためルーターがホストからのデータを分割します。
その後、受信側で分割されたデータを再構築します。

分割処理にはデメリットがあります。
ルーターの役割が増えるためルーターの処理が重くなり、分割されたデータのうち1つでも失われると復元できなくなります。
これを避けるために経路MTU が行われます。
送信ホストがルーターにデータを送信する前に、データサイズとルーターの最大転送単位が情報交換されます。
ホストはルーターの最大転送単位でデータを区切ってルーターに渡します。

まとめ

IPはTCP/IPのインターネット層プロトコルで、OSI参照モデルでは第3層ネットワーク層にあたる
IPのネットワーク層における役割は終点ノード間の通信を実現すること
IPの3つ大きな役割は「IPアドレス」「ルーティング」「分割処理と再構築処理」

AIスライド生成ツールの進捗

発表者：iwasaki_tさん

AIスライド生成ツールをVer.2にアップデートしたので発表します。

前回時点ではAIにテキスト生成のみ行わせ、スタイルが決まったHTMLにいれる方式を取っていました。
今回はテキストの配置などもAIに生成させています。

最初に指示を与えてスライドを生成したあとに修正をチャット形式で依頼することをできるようにしました。

基本的な機能は搭載できたので、今後は発表者用のメモを追加したり、アップロードしたファイルから資料を作成させたり、発表時間を指定して資料を作成させたり、便利な機能の拡充をしていきます。

エクスポートはHTMLとPDFに対応しています。
PowerPoint形式でもエクスポートできますが、装飾オブジェクトを配置させるのが難しかったため各スライドを画像化して貼り付けています。
最終的にはスライドにオブジェクトが配置されたPowerPointファイルをエクスポートできるようにしたいです。

リストの表示などは予め作成したCSSを利用するように指示しています。
デザインのカスタマイズ性が上がり、LLMがコードを書く必要がないためコストを削減できることが利点です。

今のところスライド1枚あたり$0.1~$0.3くらいで作れています。
日本円では5円くらいでしょうか。

ターゲット層を定めて機能を拡充していく予定です。

Antigravityについて

発表者：iwasaki_tさん

最近登場したAIエディタ「Antigravity」を触ってみたので知見を共有します。(2025/11末情報です)

大まかにはCursorと同じだと感じました。

個人的にはコーディングに使うモデルの選択が重要だと感じました。
例えば、Gemini 3 Proは優秀ですがトークンの消費が激しい印象があります。
とりあえずアイデアを作らせるときはCloude Sonet 4.5(Thinkingモード)を使うなど、用途に合わせてモデルを切り替えると良いです。

AIに作りたいものを伝えると、タスクとプランを作ってくれます。
チェックリスト形式で現状の全体的なプランと詳細なタスクが出力されます。
タスクには要件に合わせていくつかの選択肢が提示されることがあります。
テキストを選択してコメントを追加することができるので、選択肢を選んだり詳細な指示を与えたりすることができます。
Devinなどでは質問をコピペして回答を書き加えて送信する手間がありましたが、Antigravityでは簡単に返答できます。

タスクには重要度などに合わせてマーカーが付けられています。
重要度が高い箇所はよく読んで回答するといいです。

Antigravityは他のAIエージェントと比べてデザインに長けていると感じました。
生成物の提案にデザインコンセプトやカラーパレットが含まれており、デザイン面の細かい指示も可能です。

Antigravityはコメントを受け取って実装が開始できると判断すると勝手に実装を開始してしまいます。
実装を中断するボタンは用意されています。

Cloudeと相性が悪いようでエラーが発生してしまいます。

Antigravityは英語が標準なため、明確に日本語を使うよう指示をしないとコード内のコメントが英語で書かれてしまうことがあります。

総じてデザインやUXの面に気遣って実装してくれるところが好印象でした。

今回の反省

出向となり記事起こしにだいぶ時間をかけてしまいました。
目標を開催翌月中旬に変更しつつ、週末に進めていかなければなりませんね。