MCPって何？

Model Context Protocol（MCP）は、簡単に言うとAIモデルと外部ツールが連携するときの標準的なルールを定めたものです。

今まで、GPTやClaude等のAIモデルにWebスクレイピングやデータベース操作などの機能を追加しようとすると、それぞれ独自の方法で実装する必要がありましたが、MCPはこの問題を解決します。

要するにAIと外部ツールが話し合うための「共通言語」のようなものだと思います。

今まで、AIに「Webで検索して」とか「データベースから情報を取得して」とお願いするとき、それぞれ別々の方法で実装する必要がありましたが、MCPであれば一度覚えた方法でいろんなツールとAIを連携させることができるようになります。

技術的にはどういう仕組みなのか

MCPは、WebSocketやgRPCなどの通信プロトコルの上で動く、メッセージベースのシステムのようです。JSON形式でメッセージをやり取りして、AIとツールが情報を交換します。

特に重要だと思うのは「コンテキスト」の管理です。普通のAPIだと、一回一回のリクエストは独立していますが、MCPでは会話の流れやこれまでの処理結果を適切に管理してくれるようです。

これにより、AIが複数のツールを連続して使ったり、前回の結果を踏まえて次の行動を決めたりすることができるのではないでしょうか。

実際の開発現場でどう使えそうか

現在のAI開発で困っていることを考えると、MCPの恩恵は大きそうです。

チャットボット開発での活用

例えば、顧客サポートのチャットボットを作る場合

• CRMシステムから顧客情報を取得
• 注文履歴をデータベースから検索
• 在庫確認システムで商品状況をチェック
• メール送信システムで返答を送信

これらを全て統一的な方法で連携できれば、開発がかなり楽になります。

開発者向けAIアシスタント

コーディング支援AIの場合

• GitHubから最新のコードを取得
• 静的解析ツールでコード品質をチェック
• テスト実行環境でコードを実行
• ドキュメントを自動生成

これらのツールを組み合わせたワークフローが、MCPで簡潔に記述できるかもしれません。

実装の難しさと課題

MCPを実際に使う際の課題もあるかと思います。

学習コスト

新しいプロトコルを覚える必要があります。特に、コンテキスト管理やメッセージ形式など、従来のAPI開発とは異なる概念を理解する必要があります。

デバッグの困難さ

AIとツールの連携が複雑になると、どこで問題が発生しているかを特定するのが難しくなりそうです。適切なログ機能やデバッグツールが重要になるでしょう。

パフォーマンスの懸念

抽象化レイヤーが増えることで、多少のオーバーヘッドは必要になりそうです。高負荷なシステムでは、この影響を考慮する必要がありそうです。

まとめ

Model Context Protocolは、AI開発における「配管工事」の部分を大幅に簡略化してくれそうです。標準化により、AI開発者はより創造的で付加価値の高い部分に時間を使えるようになるでしょう。

まだ新しい技術なので、全てが確定しているわけではありませんが、AI開発に携わる者として注目していくべき技術だと思います。

実際のプロジェクトで使えるレベルになるまでには、もう少し時間がかかるかもしれませんが、早めにキャッチアップしておけば、将来的に大きなアドバンテージを得られるかもしれないです。

チームの一員として関わる中で、このギャップが将来的な問題につながる可能性を感じ、アジャイル開発手法への段階的な移行を内部で提案してみた内容をまとめました。

課題感

新しいプロジェクトに参加してすぐに感じたのは、以下のような課題でした。

1. 曖昧なタスク定義: 作業内容がざっくりと定義されているため、正確な工数見積もりができない
2. 頻繁な要件変更: 週次ミーティングでクライアントから次々と新しい要望が出てくる
3. 優先順位の不明確さ: 何を先に実装すべきかの基準がない
4. プロジェクト全体の見通しの不透明さ: 「いつまでに何ができるのか」がわからない

これらは「ウォーターフォール的アジャイル」とも呼べる状況の典型的な特徴です。

名目上はアジャイルを採用しているものの、実態はウォーターフォールに近い進め方をしており、アジャイルの利点を十分に活かせていない状態でした。

予想されるリスク

このまま進めた場合、以下のようなリスクが予想されました。

1. スケジュール管理の難しさ

タスクが明確に定義されていないため、今後の工数見積もりが困難になり、納期に間に合わない恐れがあります。

2. 要件変更への対応の限界

週次定例でクライアントから新たな要望や改善点が出され続け、それらを既存の計画にどう組み込むかの仕組みがないため、混乱が生じる可能性があります。

3. チームの疲弊

優先度が明確でないまま、次々と要件が追加されると、チームは常に「潜在的な納期遅れ」のプレッシャーにさらされ、疲弊してしまいます。

4. プロジェクトの失敗リスク

このままあいまいな状態で進めると、納期や品質に影響が出る可能性が高くなります。

アジャイル開発手法の導入プラン

これらの課題を解決するため、以下のようなアジャイル開発導入計画を立てました。

1. カンバンボードの実装

• タスクの可視化を進め、「今何が進行中で、何が待機中か」を明確にする
• ボトルネックを早期に発見できるようにする

2. ユーザーストーリーの整備

• 曖昧な要件を明確なユーザーストーリーとして再定義する
• 各ストーリーにポイント（難易度・工数の指標）を付与し、定量的な管理を可能にする

3. スプリント計画の導入

• チームの消化可能なポイント数（ベロシティ）を把握し、現実的な計画を立てる
• 2週間単位のスプリントを設定し、その期間内で達成可能な目標を設定する

期待される効果

アジャイル開発を正しく導入することで、以下のような効果が期待できます。

1. クライアントとのコミュニケーション改善

• 「今週は○○ポイントまで消化可能であり、これらの機能を実装できます」と具体的に説明できるようになる
• 追加要望があった場合、「この要望を優先すると、他のこの機能は次スプリントに持ち越しになります」と明確に提示できる
• プロジェクトの状況が「見える化」されることで、より焦点を絞った建設的な対話が可能になる

2. プロジェクト管理の透明性向上

• 進捗状況が可視化され、問題の早期発見が可能になる
• 変更による影響範囲を定量的に評価できるようになる

3. チームの持続可能な開発ペース確立

• 達成可能な目標設定により、チームは無理なく効率的に開発を進められる
• 過剰な負荷を防止し、品質を維持できる

4. リスクの低減と早期対応

• 技術的な課題や実現可能性の問題を早期に発見できるため、プロジェクト後半での大きな問題発生を防止できる
• 問題が発生しても影響範囲が限定的で、素早い対応が可能になる

クライアントとの共有ポイント

アジャイル開発への移行を成功させるためには、クライアントの理解と協力が不可欠です。以下の点をクライアントと早期に共有することにしました。

1. 優先度の明確化

• 機能の優先順位を一緒に決定することの重要性を説明する
• 「すべてが最優先」は不可能であり、限られたリソースで最大の価値を生み出すための選択が必要であることを理解してもらう

2. 変更管理プロセスの確立

• 新たな要望はプロダクトバックログに追加し、優先度に応じて取り込むプロセスを確立する
• 変更が及ぼす影響を可視化し、適切な意思決定を促す

3. 定例会議の活用方法

• スプリントレビューでは、完成した機能のデモを行い、フィードバックを得る
• スプリント計画では、次のスプリントで取り組む内容を明確にする

4. 追加要望と工数の関係

• 追加要望には追加の工数が必要であり、既存タスクとの優先度調整が必要なことを理解してもらう
• 「スコープ・時間・品質」のトレードオフ関係を明確に伝える

実施に向けた具体的なステップ

アジャイル移行の第一歩として、以下のようなステップで進める計画を立てました。

1. 現状のプロジェクト要件をユーザーストーリーとして整理

• 既存の要件をユーザーストーリー形式に書き換える
• 各ストーリーにポイントを割り当てる

2. プロダクトバックログの作成

• すべてのユーザーストーリーを優先順位順に並べたバックログを作成する
• クライアントと一緒にレビューし、優先順位を合意する

3. 初回スプリント計画

• 2週間のスプリントで取り組むストーリーを選定する
• チームのベロシティを保守的に見積もり、無理のない計画を立てる

4. カンバンボードの運用開始

• Notion等のツールを活用し、タスクの進捗を可視化する
• 日次のスタンドアップミーティングを短時間で実施し、進捗を共有する

5. 定例での振り返りと改善

• スプリントごとに振り返りを行い、プロセスの改善点を見つける
• 実績ベロシティを計測し、次回スプリントの計画に反映する

まとめ

アジャイル開発への移行は一朝一夕にはいきません。特に「アジャイルと言いながらウォーターフォール」の状態からの脱却は、チームだけでなくクライアントの考え方の変化も必要とします。

重要なのは、すべてを一度に変えようとするのではなく、小さな成功体験を積み重ねていくことです。

今回のケースでは、まずはユーザーストーリーの整備とカンバンボードの導入から始め、チームとクライアントの双方に「見える化」のメリットを実感してもらうことから始めました。

アジャイル開発の本質は、不確実性を前提とした上で、効率的にプロジェクトを進めていく柔軟性にあると思います。プロジェクトの成功確率を高め、クライアントとの良好な関係構築にもつながると考えています。

ECS Execを使用してコンテナに直接アクセスする方法を解説します。

ECS Execとは

ECS Execは、AWS ECSの実行中のコンテナに直接SSHのような形でアクセスできる機能です。この機能により、以下のようなことが可能になります。

• コンテナ内でのコマンド実行
• ログファイルの直接確認
• プロセスの状態確認
• ファイルシステムの調査

前提条件

• AWS CLIがインストールされていること
• AWSプロファイルが設定されていること
• 対象のECSタスクでECS Execが有効になっていること
• 適切なIAM権限が付与されていること

手順

1. AWS認証情報の設定

開発環境用のプロファイルを設定します：

$ export AWS_PROFILE=${profile}

2. 必要な情報の確認

ECS Execを使用するために必要な情報は以下の3つです：

1. クラスター名
2. タスクID
3. コンテナ名

これらの情報は、AWS Management ConsoleのECSダッシュボードから確認できます。

https://ap-northeast-1.console.aws.amazon.com/ecs/v2/clusters/[クラスター名]/services

3. ECS Execの実行

以下のコマンドを使用してコンテナにアクセスします：

aws ecs execute-command \
--region ap-northeast-1 \
--cluster [クラスター名] \
--task [タスクID] \
--container [コンテナ名] \
--interactive \
--command "/bin/sh"

4. シェルの変更

コンテナに接続後、より使いやすいbashシェルに切り替えます。

bash

接続エラーが発生する場合

An error occurred (InvalidParameterException) when calling the ExecuteCommand operation:
The execute command failed because execute command was not enabled on the task.

• タスク定義でECS Execが有効になっているか確認
• IAM権限が適切に設定されているか確認

容量を消費している主な原因

システムログの肥大化

システムやアプリケーションのログが /var/log に蓄積されている可能性があります。

一時ファイルの増加

• /tmpや/var/tmp に古い一時ファイルが溜まっている
• パッケージ管理ツール（例: apt）のキャッシュが大きくなっている

不要なソフトウェアや古いカーネル

• 古いカーネルや未使用のソフトウェアが残っている

ユーザーファイル

• ホームディレクトリ (/home) にある大きなファイル（動画、ISOイメージなど）が原因の可能性

不要なファイルの確認を確認する

大きなファイルを特定する

以下のコマンドで、大きなファイルやディレクトリを特定できます：

du -ahx / | sort -rh | head -n 20

• -a: ファイルとディレクトリ両方を表示
• -h: サイズを人間が読みやすい形式で表示
• -x: 他のマウントポイントを除外
• sort -rh: サイズ順に降順でソート

ログファイルをチェック

ログファイルが増大している可能性があります。以下を実行して確認：

du -sh /var/log/*

大きなログファイルがあれば、内容を確認してから削除または圧縮します：

sudo truncate -s 0 /var/log/large-log-file.log

パッケージキャッシュのクリア

不要なパッケージを削除

以下のコマンドで古いパッケージを削除します：

sudo apt autoremove

キャッシュのクリア

パッケージ管理ツールのキャッシュを削除：

sudo apt clean

一時ファイルの削除

以下で一時ファイルを削除します：

sudo rm -rf /tmp/*

また、/var/tmp もチェックしてください。

不要なカーネルの削除

古いカーネルが残っている場合、それを削除できます：

sudo dpkg --list | grep linux-image
sudo apt remove --purge linux-image-<古いバージョン>

容量不足を根本的に解決するには？

• パーティションの拡張：ディスク容量を追加するか、他のパーティションをマウントして負荷を分散します。
• 外部ストレージの利用：外付けドライブやクラウドストレージを利用してデータを移動。
• 定期的な監視：ディスク容量を監視し、定期的に不要なファイルを削除するスクリプトを作成すると便利です。

適切な監視ツールを選ぶことで、システムの稼働状況をリアルタイムで把握し、問題が発生した際に迅速に対応することが可能になります。

本記事では、個人開発者にとって導入が簡単で、無料で利用できる監視ツールを3つ紹介し、その選び方や実際の使用感について紹介します。

個人開発で導入する監視ツールの選び方

個人開発で導入する監視ツールを選ぶ際のポイントは、まず簡単に導入できることがポイントかなと思います。

開発リソースを効率的に活用するため、設定が直感的で短時間で完了するツールが理想的です。

また、無料プランが利用可能なツールを選ぶことで、コストを抑えつつ必要な監視機能を確保できます。

具体的な監視ニーズに応じて、稼働状況やエラーをリアルタイムで監視できるツールや、ウェブサイトのパフォーマンスを監視できるツールを選ぶのもありだと思います。

個人開発で導入するのにおすすめの監視ツール3選

1. UptimeRobot

特徴

ウェブサイトやサービスの稼働状況を監視し、ダウンタイムが発生するとアラートを送信します。

UptimeRobotは、HTTP(S)、Ping、ポート、キーワードのモニタリングをサポートしており、幅広い監視ニーズに対応しています。

利点

設定が非常に簡単で、初心者でも短時間で監視を開始できます。アラートはメール、SMS、Slackなどで受け取ることができ、即座に問題を把握できます。

さらに、ダッシュボードが直感的で見やすいため、監視結果を迅速に確認できます。

無料プラン

無料プランでは、50のモニタリング対象を5分間隔で監視可能です。

個人開発プロジェクトには十分な範囲で利用でき、基本的な監視機能をカバーしています。

公式サイト:

UptimeRobot: Free Website Monitoring Service

Start monitoring in 30 seconds. Use adva…

uptimerobot.com

2. Sentry

特徴

アプリケーションのエラートラッキングとパフォーマンスモニタリングを提供します。

エラーの発生場所、頻度、影響範囲をリアルタイムで把握でき、パフォーマンスの問題を素早く特定します。

多くのプログラミング言語やフレームワークに対応しており、幅広い開発環境で利用可能です。

利点

エラーをリアルタイムで検出し、詳細なスタックトレースとコンテキスト情報を提供するため、問題の原因を迅速に特定できます。

開発者フレンドリーなインターフェースを持ち、エラーの管理が簡単です。また、Sentryはパフォーマンスモニタリング機能も備えており、アプリケーションの応答時間やトランザクションの速度を詳細に分析できます。

無料プラン

一定のエラー数まで無料で利用可能で、小規模なプロジェクトや個人開発に最適です。

公式サイト:

Application Performance Monitoring & Error Tracking Software

Application performance monitoring for d…

sentry.io

3. StatusCake

特徴

ウェブサイトの稼働監視、SSL監視、ページ速度監視などを提供します。

監視対象はHTTP(S)やPing、TCPポートの他に、特定のキーワードの存在やレスポンスタイムもチェック可能です。

利点

設定が非常に簡単で、数分で監視を開始できます。アラート機能が豊富で、メール、SMS、電話、Slackなど様々な方法で通知を受け取ることができます。

世界中のロケーションからの監視が可能で、ユーザーの実際の使用感を反映した監視が行えます。また、詳細なレポート機能があり、稼働状況やパフォーマンスの変化を分析しやすくなっています。

無料プラン

基本的な監視機能を提供し、個人プロジェクトや小規模なサイトに十分対応できます。

無料プランでも主要な監視機能を利用でき、初期コストを抑えつつ監視を行うことができます。

公式サイト:

StatusCake - Uptime monitoring, Page speed monitoring, and more

Website Monitoring solution that drives …

www.statuscake.com

実際にStatusCakeを導入してみた

今回、いくつかの監視ツールを触ってみて、StatusCakeが一番サクッと設定ができたのでこちらを導入しました。

複雑な設定や知識が不要で、数分で監視を開始できました。

ウェブサイトの稼働監視では世界中のサーバからのチェックが可能で、サービスのグローバルな可用性を確認できます。

メール、SMS、Slackなど多様な方法でアラートを受け取ることができ、問題発生時に迅速に対応できそうです。

また、無料プランの提供もあり、個人開発者にとってコストは重要な要素であり、StatusCakeは無料で基本的な監視機能を利用できるため、予算を気にすることなく導入できます。

無料プランでも10のモニタリング対象を5分間隔で監視できるため、一般的な個人開発のプロジェクトでは十分に対応できそうです。

通知を設定し、実際に監視対象のページが落ちると以下のようなメールが届きます。

おわりに

今回紹介した3つの監視ツールは、いずれも設定が簡単で、個人開発者にとって扱いやすいものかと思います。

特にStatusCakeは、簡単なセットアップと多機能な監視オプションで優れたパフォーマンスを発揮します。

無料プランを利用することで、初期コストを抑えつつ、効果的な監視を行うことができますので、ぜひこれらのツールを活用してみてください！

Flutterをインストール

公式サイトからmacOS用のFlutter(flutter_macos_x.xx.x-stable.zip)をダウンロードします。

ダウンロードしたzipファイルを解凍して、任意のディレクトリに配置します。

パスを通す

解凍したフォルダを配置したらパスを通していきます。bashの場合は以下のコマンドでパスを通し反映させます。

$ echo 'export PATH="$PATH:[解凍したフォルダを配置したパス]/flutter/bin"' >> ~/.bash_profile

$ source ~/.bash_profile

flutter doctorで必要なものを確認する

以下のコマンドを実行することで、Flutterの実行環境で必要なものがわかります。

$ flutter doctor

現時点ではFlutterのみインストールしているため、他に必要なものはまだインストールされていないことがわかります。

[✓] Flutter (Channel stable, 1.22.6, on Mac OS X 10.15.2 19C57 darwin-x64, locale ja-JP)
[✗] Android toolchain - develop for Android devices
✗ Unable to locate Android SDK.
Install Android Studio from: https://developer.android.com/studio/index.html
On first launch it will assist you in installing the Android SDK components.
(or visit https://flutter.dev/docs/get-started/install/macos#android-setup for detailed instructions).
If the Android SDK has been installed to a custom location, set ANDROID_SDK_ROOT to that location.
You may also want to add it to your PATH environment variable.

[✗] Xcode - develop for iOS and macOS
✗ Xcode installation is incomplete; a full installation is necessary for iOS development.
Download at: https://developer.apple.com/xcode/download/
Or install Xcode via the App Store.
Once installed, run:
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
sudo xcodebuild -runFirstLaunch
✗ CocoaPods not installed.
CocoaPods is used to retrieve the iOS and macOS platform side's plugin code that responds to your plugin usage on the Dart side.
Without CocoaPods, plugins will not work on iOS or macOS.
For more info, see https://flutter.dev/platform-plugins
To install:
sudo gem install cocoapods
[!] Android Studio (not installed)
[!] Connected device
! No devices available

! Doctor found issues in 4 categories.

Android Studioをインストールする

公式サイトよりmacOS用のAndroid Studioをダウンロードして、インストールします。

Welcome to Android Studioの画面が出れば完了です。

Download Android Studio & App Tools - Android Developers

Android Studio provides app builders wit…

developer.android.com

Android StudioにFlutter、Dartのプラグインをインストール

Android Studioの起動画面からConfigure→Pluginsを選択します。すると以下のPluginsの画面が表示されるので、検索ボックスから「Flutter」と入力し、インストールします。

Flutterをインストールすることで同時にDartもインストールできます。

デバイスのエミュレーターをダウンロードする

エミュレーターをダウンロードしていきます。

まず起動画面から「Create New Flutter Project」を選択します。

「Flutter Application」を選択して次にいきます。

Project Nameを入力し、SDKとプロジェクトのパスを指定して次にいきます。

Finishをクリックします。

完了して編集画面が表示されたらTools→AVD Managerを選択します。

「Create Virtual Device」を選択します。

エミュレーターに使うデバイスを選択します。

System Imageを選択し、次にいきます。

最後にFinishをクリックして完了です。

Androidのライセンスを許可する

以下のコマンドでAndroidのライセンスを許可します。ライセンスの許可について聞かれるので「y」で承諾します。

$ flutter doctor --android-licenses

Xcodeをインストールする

App StoreからXcodeをインストールします。

‎Xcode App - App Store

Download Xcode by Apple on the App Store…

apps.apple.com

「Xcodeは“Macintosh HD”にはインストールできません。macOSバージョンxx.xx.x以降が必要です」とでたら、macOSのバージョンを上げるか、過去のバージョンをインストールできる方法があるようなのでどちらかで対応しましょう。

CocoaPodsをインストールする

以下のコマンドでCocoaPodsをインストールします。

$ sudo gem install cocoapods

flutter doctorで実行環境が整ったか確認する

最後にflutter doctorで実行環境が整ったか確認します。以下のようにNo issues found!となったら開発環境は完了です。

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 1.22.6, on macOS 11.2 20D64 darwin-x64, locale ja-JP)
[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
[✓] Xcode - develop for iOS and macOS (Xcode 12.4)
[✓] Android Studio (version 4.1)
[!] Connected device
! No devices available

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 1.22.6, on macOS 11.2 20D64 darwin-x64, locale ja-JP)

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
[✓] Xcode - develop for iOS and macOS (Xcode 12.4)
[✓] Android Studio (version 4.1)
[✓] Connected device (1 available)

• No issues found!

flutter doctorでFlutter plugin not installedと言われたら

Flutterのプラグインを正常にインストールできたのにnot installedと言われた場合は、以下の方法で解決しました。シンボリックリンクを作成することで認識できるようになったようです。

$ ln -s ~/Library/Application\ Support/Google/AndroidStudio4.1/plugins ~/Library/Application\ Support/AndroidStudio4.1

参考：https://github.com/flutter/flutter/issues/68429

VSCodeでFlutterが使える環境を整える

VSCodeを使っているので、Flutterが使えるようにします。

VSCodeにFlutterの拡張機能をインストールする

まず、拡張機能からFlutterをインストールします。

VSCodeでFlutter新規プロジェクトを作成する

コマンドパレットから「Flutter」と入力して、「Flutter: New Project」を選択します。プロジェクト名を入力し、ディレクトリを指定することでプロジェクトを作成できます。

エミュレーターを起動する場合は右下のNo Device選択することで、iOSとAndroidのエミュレーターを起動することができます。

ホットリロードできるようにする

コマンドパレットから「Debug: Attach to Flutter on Device」を選択することで、ホットリロードができるようになります。

TCP/IP

TCP/IP（Transmission Control Protocol/Internet Protocol）は、現在のインターネット通信において最も利用されている通信プロトコルです。

TCP/IPは複数のプロトコルからなりますが、中心的な役割を果たすのがTCPとIPであることから TCP/IPと呼ばれるようになりました。

OSI参照モデルとTCP/IP階層モデル

OSI参照モデル

OSI参照モデルとはISO(国際標準化機構)が定めた異なるベンダー間で相互通信するためのネットワーク・モデルと言われる統一規格のことです。

TCP/IP階層モデル

OSI参照モデルは7階層あるのに対し、TCP/IPは4階層しかありません。

OSI参照モデルよりも実装面で効率的 かつ 現実的な仕様となっているのがTCP/IPの階層モデルです。

TCP/IPの階層モデルの各層の主な役割は次の通りです。

• アプリケーション層：利用者が使うアプリケーションが通信するためのルールを定義
• トランスポート層：データ(セグメント)を届けるための信頼性についてのルールを定義
• インターネット層：宛先のコンピュータまでデータ(パケット)をどう届けるのかについてのルールを定義
• リンク層：LANケーブルや光ケーブル、無線などにデータを流すため、ビット列を電気信号、光信号、無線などに変える

OSI参照モデルでの層名

アプリケーション層

アプリケーション層は、ソフトウェアによる便利なサービスなどを付加するための機能を持っています。

具体的な機能としては、ファイルの転送、HTMLの閲覧、メールの送受信などがあります。

トランスポート層

ポート番号

アプリケーションが通信を行う際、アプリケーション毎に通信するデータの送受信を行うための出入り口が用意されています。

この出入り口を ポートといい、各ポートには ポート番号 が割り振られています。通信を行う際は、このポート番号を使って情報をやり取りします。

ポート番号には、0~65535番 まであり、この内0~1023番 までは通信サービス毎にあらかじめ予約されており、ウェルノウンポートといいます。

TCPとは

TCP (Transmission Control Protocol) は、IPの上位プロトコルのトランスポート層で動作するプロトコルです。

TCPの特徴

コネクション型プロトコル

TPCで通信を行う場合、まずは通信相手とのコネクションを確立させることで相手に通信が届いていることを確認させます。TCPにおいて使用されるコネクションの確立のことを3ウェイハンドシェイクと呼びます。

信頼性がある

TCPでデータ通信を行う場合は前述のとおり事前にコネクションを確立し、双方で送受信ができていることをその都度確認するため、データ転送プロトコルとしては非常に信頼性の高いと言えます。

重複を排除する仕組みがある

TCPでは重複を排除することで、データが1つであることを保障しています。例えば何らかの理由でデータが複数伝送された場合でも、TCPでは複数送信されたデータを除去する仕組みを持っています。

UDPとは

UDP(User Datagram Protocol)とは、IPやTCPなどと同様にインターネットにて標準的に利用されているプロトコルです。

UDPの特徴

コネクションレス型プロトコル

TCPはデータを伝送するために毎回コネクションを確立するコネクション型プロトコルですが、UDPはスピードを重視するため、TCPのように確認作業を行うことはありません。

このように、確認機能などを排除してデータ伝送のみを目的としたプロトコルはコネクションレス型プロトコルと呼ばれています。

処理が速い

UDPでは遅延を少なくするために、処理をできるだけ簡単にしています。

TCPのように送受信の確認を行わずデータを送信しても相手に届いたかどうかをチェックしないため、遅延するということがほとんどありません。

TCPとUDPとの比較

インターネット層

役割

インターネット層での役割は通信相手と宛先までの経路の特定です。通信における誰が誰に届けるかという重要な情報を扱っています。

また、ネットワークはコンピュータが相互に接続されているため、あるコンピュータからあるコンピュータまでの経路が複数パターン存在する場合があります。宛先までの経路が複数ある場合に、適切なルートを決定するして届けるのもネットワーク層の役割です。

IP

IPはインターネット層で中心的なやきう割を担うプロトコルでネットワーク世界における住所のようなものです。IPアドレスによってEnd to Endの通信を可能にします。

IPの特徴

パケット通信

パケット通信とは、 データをある特定の大きさに区切って伝える方法です。  宛先と発信者、何番目のデータかなどの情報(ヘッダ)を一緒につけて送ります。

コネクションレス型

コネクションレス型プロトコルでは事前にコネクションを確立しません。送信元からデータを転送しても、そのデータを通信相手が受信できるかどうかは感知しないのが特徴です。

ベストエフォート型

パケットが行き先に送られるように努力はするが、必ず到達するという保証はありません。これを補うために、IPの上でTCPというプロトコルを使い信頼性を上げています。

IPアドレス

IPアドレスにはバージョンがあり、普及しているのがIPv4です。
IPアドレス(IPv4)の構成：172.1(←ネットワーク部) .2.3(←ホスト部)

ただIPアドレス枯渇問題でIPv4(43億)では割り当てることができるIPアドレスに限界がきており、現在はIPv6(340澗)の普及が進んでいます。

ARP

ARPはIPアドレスに紐づくMACアドレスを調べるためのプロトコルです。このIPアドレスからMACアドレスを調査する一連の処理をアドレス解決と呼びます。

APRに対して知りたいMACアドレスをIPアドレスを元に依頼し、ブロードキャストを通してMACアドレスを調べてもらうイメージです。

また、何度もブロードキャストされることを防ぐために、ARPテーブルが使われます。

リンク層(ネットワークインタフェース層)

リンク層はOSI参照モデルのデータリンク層と物理層とを組み合わせたものです。

データリンク層

直結した端末同士での、電気信号の伝送制御、誤り検出、再送要求などの機能を持っています。トランスポート層と類似した役割ですが、こちらはより物理的な部分でデータというよりも電気信号そのものを扱います。

物理層

直接接続された機器や端末において、電気信号を届けるための各種機能を扱っています。

プロトコルとしては、接続するケーブルの形状やコネクタの種類などにあたります。広義の意味では、電柱を伝っている電線や光ファイバーなどもここに位置します。

イーサネット

イーサネットは データリンク層と物理層で使用されているプロトコルです。

イーサネットではインターネット層から受け取ったパケットに以下の情報を付加することによってフレームを作成します。

• プリアンブル : 受信側にフレームを 受け取る準備 をさせ、フレームが 始まることを示す値
• イーサネットヘッダー : 宛先と送信元の MACアドレスなどが記載される
• FCS : フレームが破損していないかをチェックするための値

MACアドレス

MACアドレスは物理アドレスとも呼ばれ、ネットワーク機器それぞれに、製造段階で割り当てられる装置固有の12桁の識別番号です。

インターネットなどのネットワークにおいて、コンピューター同士が通信を行う際、通信相手を特定するためにMACアドレスを利用します。

参考

クライアントとサーバー｜ヒヨコでもわかる TCP/IP 入門

zenn.dev

TCPとUDPの主な特徴6つ｜代表的なポート番号や使い分ける方法も紹介 | テックマガジン from FEnetインフラ

TCPとUDPにはどのような違いがあるのでしょうか。この記事ではTCPやUDPの…

www.fenet.jp

TCP/IP 4階層モデルとは？ | 新人エンジニアが知っておきたいネットワーク基礎知識 | Think IT（シンクイット）

【Think IT】TCP/IP 4階層モデルインターネットで使われているTCP…

thinkit.co.jp

TCP/IPの概要 | ネットワークアーキテクチャ | ネットワークのおべんきょしませんか？

TCP/IPの階層 TCP/IPは、幅広く利用されていて現在では事実上の標準とし…

www.n-study.com

Cookieとは

正式には HTTP Cookie という名称で、一般的には略してCookieと呼びます。

Cookieは、クライアント側に保存される情報のことで、Webサイトの訪問者の情報を一時的に保存します。

例えばECサイトに訪問した時に既にログイン状態になっている、以前カートに入れた商品が残っているなどは、Cookieによって実現されています。

Cookieの構成

Cookieの構成は、サーバー側で設定することができます。nameとvalueは必ず設定しなければならず、それ以外の値に任意設定です。

• name: Cookie名
• value: Cookieがもつ値
• expires: Cookieの有効期限を設定
• domain: Cookieが発行されるドメインを設定
• path: Cookieが発行されるパスを設定
• secure: アクセス先がSSLを実装しているような安全なサイトの場合のみ、Cookieを発行するように設定

1st party Cookieと3rd party Cookie

ユーザーが訪れたサイトである発行元のCookieが1st party Cookieと呼ばれ、ログイン情報などが保存されます。一方、広告などのサーバーから発行されたユーザーが訪れているサイトではない発行元のCookieが3rd party Cookieになります。

まとめると以下のような違いがあります。

• 1st Party Cookieは、ユーザーが訪れたサイト(自社サイト)での用途に使う
• 3rd Party Cookieは、ユーザーが訪れたサイトでないサイト(他社サイト)での用途に使う

広告はターゲティングや効果測定のためにサイトをまたがってユーザーを識別する必要があります。これを実現するために3rd Party Cookieを使用しています。

3rd Party Cookieにより、ユーザーがどんなサイトを見ているかなどの情報を収集できてしまいます。

そのため、個人情報保護の観点からAppleはITP (Intelligent Tracking Prevention) という仕組みを自社ブラウザであるSafariに導入し、広告目的のクッキー(Cookie)の使用が制限され始めています。

Session

Sessionは通信における開始から終了までの一連の処理のことで、ここではCookieを使用した一連の操作・仕組みのことを指します。

Sessionはログイン情報など、ユーザーと紐づく情報をサーバー側に一定期間保存しておくことができます。

CookieとSession

SessionにIDを割り振って管理し、保持されたSessionが欲しいときはIDを指定して取り出します。

クライアント側でこのSessionIDをCookieに格納し、CookieはHTTPリクエスト時に自動的にCookie情報を送受信するため、サーバー側は送信されたSessionIDを元にユーザーの識別が可能となります。

クライアント側はSessionのIDは改ざんできても関連している中身はサーバーにあるからデータの改ざんすることはできません。

このようにCookieを利用することで、Session管理をすることができます。

Web Storageとは

Web Storageはクライアント側にデータをローカル環境に記録するための仕組みです。

同じような仕組みとしてCookieが使われていますが、Web Storageはより高機能で扱いやすくなっています。ほとんどのモダンブラウザがWeb Storageに対応しており、InternetExplorerもバージョン8以上から対応しています。

Web Storageの使いどころ

Web Storageはクライアント側からアクセスできるデータベースのような役割をしています。

そのため、クライアント側であるJavascriptからアクセスしてメリットがあるような使い方をすると良いかと思います。

例えば以下のような場合に効果を発揮します。

• お知らせや通知など表示に関する各種設定情報
• お気に入りや商品のカート追加などのユーザーによる操作やアクションによる情報

Web Storageの種類とCookieとの比較

Web StorageはさらにlocalStorageとsessionStorageの2種類に分かれ、保持するデータの有効期限に違いがあります。

CookieとWeb Storageの共通点と違い

共通点

• クライアントから参照をすることができる
• 保存するデータをKey-Valueで保存する

異なる点

• Web Storageは大きなデータ量を簡単に取り扱える
• Cookieは通信ごとに毎回自動で送信される

また大きな用途の違いとして、Cookieの情報はサーバーサイドが使用するのに対し、Web Storageはクライアントサイドからしか参照することができません。

基本的にはCookieにはJavascriptからアクセスできず、Web StorageはJavascriptによってアクセスできるため、サーバーで参照する必要がないデータはWeb Storageで格納すると良いでしょう。

Web StorageとCookieを比較した場合、通信量やセキュリティなどほとんどの面でWeb Storageに軍配があがりますが、CookieはHTTPリクエスト時に自動的にCookie情報を送受信するため、単純にサーバー側プログラムとの連携を考えると、Cookieの方が扱いやすいといえます。

参考

Web Storageでローカルに情報を記録する - 第3章 応用・JavaScript関連技術 - [SMART]

Web Storageの概要 Web Storageはクライアント側にデータをロ…

rfs.jp

Cookieとセッションをちゃんと理解する #PHP - Qiita

引用/参考書籍 「よくわかるPHPの教科書」 「初めてのPHP5」 「パーフェク…

qiita.com

【PHP超入門】Cookieとセッションについて #HTTP - Qiita

Udemy で講座の販売を開始しました！ Udemy で「プログラミング学習の心…

qiita.com

【解説】「サードパーティークッキーとマーケティングの 現在とこれから」クッキーの基本を理解して、未来を読み解く｜Kaizen Platform 公式note

最近起きていること Kaizen Platform CTOのwatabeです。 …

media.kaizenplatform.com

Google Analytics Reporting APIの設定準備

Google Analytics Reporting APIの設定は以下の記事を参考にしました。

• プロジェクトの作成
• サービスアカウントの作成
• 秘密鍵のJSONファイルを生成 ← あとで使います
• Googleアナリティクスにユーザ追加
• ビューIDの確認 ← あとで使います

参考：Google Analytics API を叩いてデータを取得するまでの流れ（Ruby）

RailsでGoogleアナリティクスレポートデータ取得処理をクラス化

Googleアナリティクスレポートデータ取得処理を独自クラス化し、コントローラで使えるようにします。

先程生成した秘密鍵のJSONファイルは「analytics_auth.json」として配置し、authメソッドでGoogleアナリティクスAPIに認証を行ってからレポートデータを取得しにいきます。

report_pv_count_by_dateメソッドで、取得開始日と取得終了日を引数(デフォルトは当日)で指定してその期間のレポートデータを取得できるようにします。

・lib/analytics.rb

require 'google/apis/analyticsreporting_v4'

class Analytics

  # レポート対象を指定してオブジェクトを生成
  # @param [String] base_url レポート対象サイトのURL
  # @param [String] view_id ビューID
  def initialize(base_url, view_id)
    @base_url = base_url
    @view_id = view_id
    @analytics = Google::Apis::AnalyticsreportingV4
    auth
  end

  # 指定した期間のページごとのPVを集計
  # @param [String] date 日付を表す文字列
  # @return [Hash] 累計PV及びページごとのPV
  def report_pv_count_by_date(start_date = 'today', end_date = 'today')
    date_range = @analytics::DateRange.new(start_date: start_date, end_date: end_date)
    metric = @analytics::Metric.new(expression: 'ga:users', alias: 'users')
    dimension = @analytics::Dimension.new(name: 'ga:pagePath')
    order_by = @analytics::OrderBy.new(field_name: 'ga:users', sort_order: 'DESCENDING')
    request = @analytics::GetReportsRequest.new(
      report_requests: [@analytics::ReportRequest.new(
        view_id: @view_id,
        metrics: [metric],
        date_ranges: [date_range],
        dimensions: [dimension],
        order_bys: [order_by],
      )]
    )
    response = @client.batch_get_reports(request)
    data = response.reports.first.data
    return {
      total: data.totals.first.values.first,
      pages: data.rows.map do |row|
        {
          url: @base_url + row.dimensions.first,
          dir: row.dimensions.first,
          views: row.metrics.first.values.first
        }
      end
    }
  end

  private

  # GoogleアナリティクスAPIに認証
  # 同ディレクトリにanalytics_auth.jsonを配置
  def auth
    scope = ['https://www.googleapis.com/auth/analytics.readonly']
    @client = @analytics::AnalyticsReportingService.new
    @client.authorization = Google::Auth::ServiceAccountCredentials.make_creds(
      json_key_io: File.open('analytics_auth.json'),
      scope: scope
    )
  end

end

独自クラスを作成したら、呼び出せるようにapplication.rbに以下を追記します。

・config/application.rb

require_relative 'boot'

require 'rails/all'

# Require the gems listed in Gemfile, including any gems
# you've limited to :test, :development, or :production.
Bundler.require(*Rails.groups)

module AppName
  class Application < Rails::Application

    ...

    # 独自クラスパス指定
    config.autoload_paths += %W(#{config.root}/lib) ←追加

    ...

  end
end

uninitialized constantエラーで定義したクラスを読むことができない場合は、config/initializersディレクトリ配下にrequirements.rbファイルを作成し、以下を追記してください。

・config/initializers/requirements.rb

require Rails.root.join('lib/analytics.rb')

クラス化したGoogleアナリティクスレポートデータ取得メソッド呼び出し

実際にコントローラで呼び出してみます。初期化のBASE_URLとVIEW_IDは環境変数として.envに設定し呼び出して使うようにします。

フロントからパラメータ(取得開始日・取得終了日)をPOSTし、それらを引数にして実行しています。レスポンスはJSON形式で返すようにしています。

あとはroutes.rbにルーティングを設定して完了です。

・app/controllers/api/analytics_controller.rb

class Api::AnalyticsController < Api::ApplicationController

  def report
    analytics = ::Analytics.new(ENV['BASE_URL'], ENV['VIEW_ID'])

    render json: analytics.report_pv_count_by_date(params[:start_date], params[:end_date])
  end

end

以上、RailsでGoogle Analytics Reporting APIでレポートデータ取得する方法でした。

参考：LINE謎の開発についてまとめ

参考：プログラミング初心者でも無料で簡単にLINE BOTが作れるチュートリアル｜渡なべ達明｜note

参考：【入門】Google Apps ScriptでLINE botを作成する

特にこちらのKindle本ではとてもわかりやすく解説されています。こちらの本では実際に作られている謎解きやマーケティング戦略まで紹介されているので、ご一読することをおすすめします。

LINE謎とは

LINEの公式アカウントを用いて、主にBot形式で謎を出題する謎解き形式をLINE謎と呼ばれています。

LINEのアカウントさえあれば、手軽に謎解きに挑戦することができます。LINEのMessaging APIが開放されてからLINE謎が出現し、少しずつ広まってきているようです。

LINE謎開発の事前準備

事前準備として以下が必要となります。今回は参考記事通りにGAS(Google App Script)を使用してコーディングを行っています。Googleアカウントは登録された前提とします。

• Googleアカウント登録
• LINE Developers登録
• LINE Bot Designer(必須ではない)

LINE Developersの登録

まず、以下のリンクからLINE開発者登録を行います。既にLINEアカウントを持っている場合は、そのアカウントで登録することができます。QRコードログインで簡単に認証することができます。

LINE Developers

LINE Bot Designerのダウンロード

LINE Bot Designerを使用することで、簡単かつ短時間でLINE Botのプロトタイプを作成することができます。GUIで感覚的にチャットボットを設計できます。

以下のリンクからLINE Bot Designerをダウンロードします。後ほど使用しますので、その後インストールまでやっておきましょう。

LINE Bot Designer

Messaging APIで新規チャンネルを作成

先ほど登録したLINE Developersにログインし、「新規チャンネル作成」を押します。新規チャンネル作成に必要な項目を入力します。

ここで作成するLINE謎のチャンネル名やアイコンなどを登録します。なおチャンネル名は7日間は変更できないため、注意が必要です。

LINE Messaging API：Messaging APIの特徴 Messaging APIは

GASからWebhook URLを取得する

まず、自身のGoogleアカウントからGoogleドライブを開き、Googleスプレッドシートを新規作成します。

スプレッドシートを開いたら、「ツール」→「スクリプトエディタ」を選択します。

選択すると、以下のようなスクリプトエディタが表示されます。左上にあるプロジェクト名を入力し、「公開」→「ウェブアプリケーションとして導入」を選択してください。

それぞれ、以下のように設定し「Deploy」を押下します。

表示された「Current web app URL」をコピーします。これがWebhook URLとなります。

LINE DevelopersのWebhook設定でGASと連携する

作成したチャンネルからMessaging API設定を選択します。下にあるWebhook設定のWebhook URLに先ほどコピーしたURLをペーストします。また、Webhookの利用をONにします。

次にさらに下にあるチャンネルアクセストークンの発行を行います。このチャンネルアクセストークンは後で使います。

GAS(Google App Script)を使って、ユーザとの応答形式LINE Botのスクリプトを実装する

GASの画面に戻り、ユーザとの応答形式のスクリプトを実装していきます。JavaScriptで書くことができます。

チャンネルアクセストークンの設定とリクエスト判定

まずはじめにチャンネルアクセストークンを設定します。先ほど発行したチャンネルアクセストークンを変数に代入しましょう。

次にユーザから送られてくるリクエスト判定を行います。event.typeによって友達追加かメッセージかを判定します。

// チャンネルアクセストークンを設定
var channel_access_token = "先ほど発行したチャンネルアクセストークン";

// ユーザからのリクエスト判定(友達追加またはメッセージ)
function doPost(e) {
  var events = JSON.parse(e.postData.contents).events;
  events.forEach(function(event) {
    if (event.type == "message") {
      sendMessage(event);
    }
    if (event.type == "follow") {
      sendFollowMessage(event);
    }
  });
}

友達追加時の挙動

ユーザから友達追加された際に返すメッセージを設定します。setFollowMessageで友達追加時のメッセージ用意し、ユーザに返します。

function sendFollowMessage(e) {
  var followMessage = setFollowMessage(e);
  var postData = {
    "replyToken": e.replyToken,
    "messages": followMessage
  };
  var options = {
    "method": "post",
    "headers": {
      "Content-Type": "application/json",
      "Authorization": "Bearer " + channel_access_token
    },
    "payload": JSON.stringify(postData)
  };
  UrlFetchApp.fetch("https://api.line.me/v2/bot/message/reply", options);
}

// 友達追加された際に返すメッセージ
function setFollowMessage(e) {
  var message = [{
    "type": "text",
    "text": "友達追加ありがとうございます！"
  }];
  return (message)
}

メッセージが送られてきた際の挙動

友達追加時と同様にsetMessageに送られてきたメッセージに対応する返信を用意します。

switch文でそれぞれのメッセージに対応する返信を書いていきます。これがユーザとの応答形式Botの中身になります。LINE謎の場合は答えやヒントなどに対応する返信を書いていくことになります。

defaultは想定していないメッセージが送られてきた場合の返信を書きます。

function sendMessage(e) {
  var message = setMessage(e);
  var postData = {
    "replyToken": e.replyToken,
    "messages": message
  };
  var options = {
    "method": "post",
    "headers": {
      "Content-Type": "application/json",
      "Authorization": "Bearer " + channel_access_token
    },
    "payload": JSON.stringify(postData)
  };
  UrlFetchApp.fetch("https://api.line.me/v2/bot/message/reply", options);
}

// メッセージが送られてきた際に返す返信の条件分岐
function setMessage(e) {
  switch (e.message.text) {
    case "答え":
      var message = [
        {
          "type": "text",
          "text": "正解です。"
        }
      ];
      return(message)
      break;

  case "ヒント":
    var message = [
      {
        "type": "text",
        "text": "ヒントは〇〇です。"
      }
    ];
    return(message)
    break;

  default:
    var message = [
      {
        "type": "text",
        "text": "ヒントが欲しい場合は「ヒント」と入力してください。"
      }
    ];
    return(message)
    break;
  }
}

以上で応答形式Botの完成です。完成後は、「公開」→「ウェブアプリケーションとして導入」を選択し、バージョンを「new」にして再度デプロイしましょう。すると反映されていることが確認できると思います。

返信メッセージをリッチにしたい

返信メッセージをもっとリッチにしたい場合は、先ほどインストールしたLINE Bot Designerを使ってみましょう。

インストールが完了後、プロジェクトを作成を選択します。

プロジェクトの設定を行います。

設定完了後、プロトタイプをGUIで作成することができます。プロトタイプ完成後、右下のJSONをコピーすることで、そのまま使用することができます。

ここで画像・動画、テンプレートメッセージなどを設計し、JSONコードをそのままGASにコピペで使うことができます。LINE謎を作成する場合は画像などを使うと思いますので、こちらを積極的に活用してみましょう。

実際にLINE謎を作ってみた

実際にLINE謎を作ってみました。ざっくりストーリーから考え、次にストーリーにあわせた謎を作り、開発という流れで行いました。こういう謎解きを作るのは初めてでしたが、丸一日かけて公開まで漕ぎ着けることができました。

初心者向けのLINE謎で10分くらいで解けるので、もし時間があればやっていただけると嬉しいです。

地球最後の日に残された謎：https://lin.ee/tV2tCPuy