弊社で毎月開催し、 PHP エンジニアの間でご好評をいただいている PHP TechCafe。 2022年11月のイベントでは「 PHP フレームワーク 」について語り合いました。 弊社メンバーがピックアップした PHP の代表的な フレームワーク ４種について、以下のShowNoteをベースに、参加者の皆様のご意見も伺いながら学んでいきました。今回はその内容についてレポートします。 rakus.connpass.com hackmd.io フレームワークとは 代表的なPHPフレームワーク Laravel Symfony CakePHP Slim 機能比較 ルーティング Laravel Symfony CakePHP Slim まとめ セッション管理 Laravel Symfony CakePHP Slim まとめ リクエスト管理 Laravel Symfony CakePHP Slim まとめ エラーハンドリング Laravel Symfony CakePHP Slim DBサポート Laravel Symfony CakePHP Slim 最後に フレームワーク とは まず初めに、 フレームワーク とは、 アプリケーション開発においてよく利用される機能をあらかじめ備えた枠組み のことです。 もう少し具体的に説明すると、以下の通りです。 Webアプリケーション フレームワーク 動的な ウェブサイト、Webアプリケーション、 Webサービス の開発をサポートするために設計されたアプリケーション フレームワーク Web開発で用いられる共通した作業に伴う労力を軽減する データベースへのアクセス テンプレートエンジン セッション管理 何故 フレームワーク が必要なのか？ 開発速度向上 Webアプリケーション開発でよく利用する処理（セッション管理やDBアクセス、 Cookie など）が既に用意されているため、それらを再利用するだけで開発が進められる セキュリティ対応 脆弱性 が見つかった場合に修正版がリリースされる 開発ルールの順守 フレームワーク のルールに従って作成することが強いられる反面、開発チーム全体で共通のルールで開発できるため、ルールに逸脱するようなコードが生まれにくい ここでは、「セキュリティに関わる実装を自前で組むメリットは少ないため、実績のある フレームワーク を利用することが一番の正攻法ではないか」といった意見が挙がっていました。 代表的な PHP フレームワーク 次に、事前に弊社メンバーが抜粋した、代表的な PHP フレームワーク それぞれの設計思想について語り合いました。 （抽出対象や並び順に意図はございません） Laravel laravel.com プログレ ッシブ フレームワーク どのような規模や段階の Web アプリケーションにも対応できる フレームワーク の概念 依存性注入、 単体テスト 、キュー、リアルタイム イベント などのための堅牢なツールを提供 スケーラブルな フレームワーク システム規模や利用負荷などの増大に対応できる Laravel アプリケーションは、1 か月あたり数億のリク エス トを処理するように簡単にスケーリングされている コミュニティ フレームワーク コミュニティの活動が活発であり、意見交換も頻繁に行われている 参加者からは「確かにイー ジー なイメージがあり、何でもできて簡単。」といった意見や、「依存性注入や 単体テスト のために独自に拡充された機能が提供されており、色々出来て便利」といった意見が挙がりました。Laravleにはサー ビスコ ンテナと呼ばれる機能が備わっているため、依存性注入を簡単に行うことができたり、 ユニットテスト を考慮して構築されていることがその理由となります。 Symfony symfony.com 作成された コンポーネント を組み合わせて、 フルスタックフレームワーク を作成することもマイクロサービスを作成することも可能 開発者の目的に応じて規模を変えることができることが特徴 コンポーネント が標準化されており、アプリケーションが成熟しても使用したい コンポーネント を自由に導入することができる Java の Spring Framework や Ruby の Ruby on Rails の影響を受けている Symfony コンポーネント は Drupal , Prestashop , Laravel 　で利用されている ここでは、 Symfony 自体がLaravelの中で使われているという点について活発にコメントが飛び交いました。 「 Symfony のリリースが遅れることによってLaravelにも影響が出たケースがあった」という声や、「Laravelのリリース頻度が Symfony のバージョンアップに依存するような形になったということを過去に記事で見た」という声です。 現時点の最新バージョンであるLaravel9についても、 Symfony の コンポーネント に依存していることが要因となりLTS（※LTSはLong Term Supportの略で長期サポートを意味）がなくなったりと、実際に様々な影響を及ぼしていることから、このような声が多く挙がっているようです。 CakePHP cakephp.org 「ケーキを焼くくらい簡単に開発できる」というコンセプトで設計されており、初心者向けであるといえる Ruby on Rails の概念の多くが取り入れられている 比較的小規模なWeb アプリ開発 向けである 「 MVC モデル」が採用されており、役割分担をさせて高速に開発を進められる ここでは、「 MVC に準拠しており、 命名 がすごく厳格だという印象がある」という意見が挙がりました。 Slim www.slimframework.com www.slimframework.com シンプルかつ強力な Web アプリケーションと API をすばやく作成するのに役立つ PHP マイクロ フレームワーク 必要なことだけを行う最小限のツール セットのみを提供 最小限の機能のみを持つため、ルールがシンプルで、開発の自由度が高く、学習コストが低い ここでは、マイクロ フレームワーク を謡っているという点について「テンプレートエンジンが標準で提供されておらず、細かな Bot 作成や小さな機能開発を行う際に利用しやすい」といった意見や、「自由に拡張できるという点がありがたい」といった意見が挙がりました。 機能比較 続いて、各 フレームワーク の基本的な利用方法に注目し、それぞれの特徴について比較しながらディスカッションを行いました。 ルーティング Laravel laravel.com ルートファイル デフォルトでは下記２つファイルにルーティングを定義する routes/web. php routes/ api . php 定義方法 UserControllerにindexメソッドを定義している場合、下記のように定義すると /user のパスに対して、UserControllerのindexメソッドが対応される <?php use App\Http\Controllers\UserController; Route :: get ( '/user' , [ UserController :: class , 'index' ]) ; 利用可能な ルーター メソッド <?php Route :: get ( $ uri , $ callback ) ; Route :: post ( $ uri , $ callback ) ; Route :: put ( $ uri , $ callback ) ; Route :: patch ( $ uri , $ callback ) ; Route :: delete ( $ uri , $ callback ) ; Route :: options ( $ uri , $ callback ) ; パラメータ <?php Route :: get ( '/posts/{post}/comments/{comment}' , [ CommentController :: class , 'show' ]) ; ここでは「 Route::get や Route::post のように、複数のHTTP動詞に対応したルートを登録できることが特徴的である」という意見が挙がりました。 Symfony routes.yaml に記載するパターン /lucky/number にアクセスすることで LuckyController の number メソッドにルーティングされる app_lucky_number : path : /lucky/number controller : App\Controller\LuckyController::number アノテーション または アトリビュート を利用するパターン(こちらが推奨) コントローラを以下の通り変更することで routes.yaml を作成しなくともルーティングが行われる <?php // src/Controller/LuckyController.php namespace App\Controller; use Symfony\Component\HttpFoundation\Response; use Symfony\Component\Routing\Annotation\Route; class LuckyController { #[Route('/lucky/number')] public function number () : Response { $ number = random_int ( 0 , 100 ) ; return new Response ( '<html><body>Lucky number: ' .$ number . '</body></html>' ) ; } } ここでは「ルーティングの方法が複数ある」という点に注目が集まりました。 「デフォルトは routes.yaml だが推奨パターンは アトリビュート を使うパターンのようだ」といった声や、「サンプルコードのような アトリビュート を使うパターンが分かりやすい」といった声が挙がりました。 CakePHP book.cakephp.org routes.php に記載 　例： / にアクセスすると ArticlesController の index() メソッドを実行する <?php use Cake\Routing\Router; // スコープ付きルートビルダーを使用。 Router :: scope ( '/' , function ( $ routes ) { $ routes -> connect ( '/' , [ 'controller' => 'Articles' , 'action' => 'index' ]) ; }) ; // static メソッドを使用。 Router :: connect ( '/' , [ 'controller' => 'Articles' , 'action' => 'index' ]) ; 　 /articles/15 にアクセスすると ArticlesController の view(15) メソッドを実行する <?php $ routes -> connect ( '/articles/:id' , [ 'controller' => 'Articles' , 'action' => 'view' ] ) -> setPatterns ([ 'id' => '\d+' ]) -> setPass ([ 'id' ]) ; 　HTTPメソッドによって分けたいときは以下のような記述を行う <?php // GET リクエストへのみ応答するルートの作成 $ routes -> get ( '/cooks/:id' , [ 'controller' => 'Users' , 'action' => 'view' ] , 'users:view' ) ; // PUT リクエストへのみ応答するルートの作成 $ routes -> put ( '/cooks/:id' , [ 'controller' => 'Users' , 'action' => 'update' ] , 'users:update' ) ; ここでは「必ずしもルーティングは必要でなく、URLから勝手にクラスを推測してくれる」という点に注目が集まりました。 しかし、「知らないと迷いそうなので明記して欲しい」といった声もあり、やはり明示的に定義するのがベストだろうという考えに落ち着きました。 Slim www.slimframework.com get() ／ post() メソッドを使用 <?php $ app -> get ( '/books/{id}' , function ( $ request , $ response , array $ args ) { // Show book identified by $args['id'] }) ; <?php $ app -> post ( '/books' , function ( $ request , $ response , array $ args ) { // Create new book }) ; ここではルータメソッドが get() ／ post() であることから「Laravelと似ている」という意見が挙がりました。 まとめ ルーティングの利用方法に関して全体を見渡した後には、以下のような意見が挙がりました。 Symfony ： アトリビュート によるルーティングが特徴的 CakePHP ：ルーティングを記載せずとも フレームワーク で勝手に呼び出すクラスを推測してくれる点が特徴的 Laravel： Routes を見に行く必要があることが面倒である、 C# のルーティング定義に似ている 全般：どこで何をやっているのかが分かるルーティングの方法であることが望ましい composerのインストール／アップデートのように、1つの操作が複数の役割を持つような仕組みは分かりづらい セッション管理 続いて、セッション管理の方法について見ていきます。 Laravel laravel.com 設定ファイル config/session. php セッションの操作方法 グローバルセッションヘルパー と Requestインスタンス経由 の2つの方法がある 　　 　・グローバルセッションヘルパー <?php $ value = session ( 'key' ) ; 　　 　・Request インスタンス 経由 <?php public function show ( Request $ request , $ id ) { $ value = $ request -> session () -> get ( 'key' ) ; // } Symfony セッションの操作方法 RequestStack と RSessionInterface から取得する2つの方法がある RequestStack から取得するパターン セッションの設定は config/packages/framework.yaml に記載 HttpFoundation component を追加することで利用可能 その他の詳細 基本的な使い方 <?php use Symfony\Component\HttpFoundation\RequestStack; class SomeService { private $ requestStack ; public function __construct ( RequestStack $ requestStack ) { $ this -> requestStack = $ requestStack ; // Accessing the session in the constructor is *NOT* recommended, since // it might not be accessible yet or lead to unwanted side-effects // $this->session = $requestStack->getSession(); } public function someMethod () { $ session = $ this -> requestStack -> getSession () ; // stores an attribute in the session for later reuse $ session -> set ( 'attribute-name' , 'attribute-value' ) ; // gets an attribute by name $ foo = $ session -> get ( 'foo' ) ; // the second argument is the value returned when the attribute doesn't exist $ filters = $ session -> get ( 'filters' , []) ; // ... } } SessionInterface から取得するパターン SessionInterface でタイプヒントしてコントローラ引数に渡すだけ 基本的な使い方 <?php use Symfony\Component\HttpFoundation\Response; use Symfony\Component\HttpFoundation\Session\SessionInterface; // ... public function index ( SessionInterface $ session ) : Response { // stores an attribute for reuse during a later user request $ session -> set ( 'foo' , 'bar' ) ; // gets the attribute set by another controller in another request $ foobar = $ session -> get ( 'foobar' ) ; // uses a default value if the attribute doesn't exist $ filters = $ session -> get ( 'filters' , []) ; // ... } CakePHP book.cakephp.org PHP のネイティブ session 拡張上に、ユーティリティ機能のスイートとラッパーを提供 設定 　・データベースセッション 　　・セッションをデータベースに保持することを指定 　　・セッション保持するためのカスタムモデルを定義することもできる(model => 'CustomSessions') <?php 'Session' => [ 'defaults' => 'database' , 'handler' => [ 'engine' => 'DatabaseSession' , 'model' => 'CustomSessions' ] ] 　　・キャッシュセッション 　　　・CacheSession クラスをセッション保存先として 指定 <?php Configure :: write ( 'Session' , [ 'defaults' => 'cache' , 'handler' => [ 'config' => 'session' ] ]) ; セッションの利用 リク エス トオブジェクトを呼び出せる場所ならどこでも呼び出せる Controllers Views Helpers Cells Components <?php $ name = $ this -> getRequest () -> getSession () -> read ( 'User.name' ) ; // 複数回セッションにアクセスする場合、 // ローカル変数にしたくなるでしょう。 $ session = $ this -> getRequest () -> getSession () ; $ name = $ session -> read ( 'User.name' ) ; 利用するメソッド Session::read($key) Session::write($key) Session::check($key) Session::destroy() Slim なし まとめ セッションについては、それぞれの フレームワーク で利用方法が多岐に渡りました。 ここでは、 CakePHP について、「セッションの参照に Get ではなく Read になっているのは何故なのか？」といったコメントや、Slimにはそもそも実装されていない点について、「それがSlimの良いところであり、必要であればcomposerで導入すればよい」といったコメントが挙がっていました。 リク エス ト管理 Laravel laravel.com <?php $ name = $ request -> input ( 'name' ) ; $ name = $ request -> query ( 'name' ) ; Laravelでは Request クラスの インスタンス から取得します。 Symfony symfony.com <?php use Symfony\Component\HttpFoundation\Request; use Symfony\Component\HttpFoundation\Response; public function index ( Request $ request ) : Response { $ request -> isXmlHttpRequest () ; // is it an Ajax request? $ request -> getPreferredLanguage ([ 'en' , 'fr' ]) ; // retrieves GET and POST variables respectively $ request -> query -> get ( 'page' ) ; $ request -> request -> get ( 'page' ) ; // retrieves SERVER variables $ request -> server -> get ( 'HTTP_HOST' ) ; // retrieves an instance of UploadedFile identified by foo $ request -> files -> get ( 'foo' ) ; // retrieves a COOKIE value $ request -> cookies -> get ( 'PHPSESSID' ) ; // retrieves an HTTP request header, with normalized, lowercase keys $ request -> headers -> get ( 'host' ) ; $ request -> headers -> get ( 'content-type' ) ; } Symfony もLaravelと同じ様に Request クラスの インスタンス から取得します。 CakePHP <?php $ controllerName = $ this -> request -> getParam ( 'controller' ) ; // URL は /posts/index?page=1&sort=title の場合に page を取得するとき $ page = $ this -> request -> getQuery ( 'page' ) ; //　POSTデータにアクセスするとき $ title = $ this -> request -> getData ( 'MyModel.title' ) ; CakePHP もLaravel、 Symfony と似たイメージです。 Slim www.slimframework.com <?php use Psr\Http\Message\ResponseInterface as Response; use Psr\Http\Message\ServerRequestInterface as Request; use Slim\Factory\AppFactory; require __DIR__ . '/../vendor/autoload.php' ; $ app = AppFactory :: create () ; $ app -> get ( '/hello' , function ( Request $ request , Response $ response ) { $ response -> getBody () -> write ( 'Hello World' ) ; return $ response ; }) ; $ app -> run () ; セッション管理は実装されていませんでしたが、リク エス ト管理はSlimにもちゃんと実装されています。 まとめ ここでは、「いずれもRequestクラスの インスタンス から取得するという点において、だいたいどれも似たような形である」といった意見や、「これが フレームワーク の大本みたいな感じがする」といった意見が挙がりました。 Webアプリケーションの基本となる部分であることからも、それぞれの フレームワーク に大きな差はないようでした。 エラーハンドリング Laravel readouble.com App\Exceptions\Handler クラスによって、アプリケーションが投げるすべての例外がログに記録され、ユーザーへレンダーされる エラーハンドリングのカスタマイズ Handler クラスは、カスタム例外レポートと レンダリング コールバックを登録できる register メソッドを持っている。 reportable メソッドで、例外をさまざまな方法で報告できる。（エラー監視ツールに登録するなど。デフォルトではログに記録される。） renderable メソッドで、特定の例外に対して、個別に レンダリング 方法を指定することができる。(デフォルトでは例外はHTTPレスポンスに変換される) HTTPエラーが返された場合、 resources/views/errors 下の HTTPステータスコード 名のbladeファイルが レンダリング される（ 404.blade.php など） <?php use App\Exceptions\InvalidOrderException; /** * アプリケーションの例外処理コールバックを登録 * * @return void */ public function register () { $ this -> reportable ( function ( InvalidOrderException $ e ) { // 例外を報告 }) ; $ this -> renderable ( function ( InvalidOrderException $ e , $ request ) { return response () -> view ( 'errors.invalid-order' , [] , 500 ) ; }) ; } Laravelの場合、例外を投げた際にデフォルトのものを使うか別のカスタマイズされたものを使うか振り分けることができます。 例えば、404エラーの場合は 404.blade のように定義しておけば、自動で読み込んで画面に表示してくれます。 Symfony symfony.com github.com エラーが 404 Not Found エラーであろうと、コードで何らかの例外をスローすることによってトリガーされた致命的なエラーであろうと、すべてのエラーを例外として扱う。 組み込みの Twig エラーレンダラーを使用して、デフォルトのエラーテンプレートをオーバーライド可能。 composer require symfony/twig-pack これらのテンプレートをオーバーライドするには、標準の Symfony メソッドを使用し て、バンドル内にあるテンプレートをオーバーライドし、それらを templates/bundles/TwigBundle/Exception/ ディレクト リに配置する Copy templates/ └─ bundles/ └─ TwigBundle/ └─ Exception/ ├─ error404.html.twig ├─ error403.html.twig └─ error.html.twig # All other HTML errors (including 500) ここでは Twig に関して、デフォルトのエラーテンプレートをオーバーライドする際の利用方法が分かり易いといったコメントが挙がりました。 CakePHP book.cakephp.org <?php * ErrorController にてエラーページを描画 namespace App\Controller\Admin; use App\Controller\AppController; use Cake\Event\EventInterface; class ErrorController extends AppController { /** * Initialization hook method. * * @return void */ public function initialize () : void { $ this -> loadComponent ( 'RequestHandler' ) ; } /** * beforeRender callback. * * @param \Cake\Event\EventInterface $event Event. * @return void */ public function beforeRender ( EventInterface $ event ) { $ this -> viewBuilder () -> setTemplatePath ( 'Error' ) ; } } ここでは、「Cakeの場合はデフォルトのエラーテンプレートをオーバーライドするというより Controller をそれぞれ作るイメージだ」とのコメントがありました。 Slim www.slimframework.com slimが用意したエラー画面を出すかどうかを選択できたり、カスタムエラー画面を表示するなど柔軟な設定が可能 <?php use Slim\Factory\AppFactory; require __DIR__ . '/../vendor/autoload.php' ; $ app = AppFactory :: create () ; /** * The routing middleware should be added earlier than the ErrorMiddleware * Otherwise exceptions thrown from it will not be handled by the middleware */ $ app -> addRoutingMiddleware () ; /** * Add Error Middleware * * @param bool $displayErrorDetails -> Should be set to false in production * @param bool $logErrors -> Parameter is passed to the default ErrorHandler * @param bool $logErrorDetails -> Display error details in error log * @param LoggerInterface|null $logger -> Optional PSR-3 Logger * * Note: This middleware should be added last. It will not handle any exceptions/errors * for middleware added after it. */ $ errorMiddleware = $ app -> addErrorMiddleware ( true , true , true ) ; // ... $ app -> run () ; ここでは、Slimにはテンプレートエンジンがないことから、「用意したエラー画面を出すかカスタムエラーを出すか」であり、リク エス ト時に Add Error Middleware の設定を行うことでエラーハンドリングを有効／無効化が制御できるという説明がありました。 DBサポート Laravel readouble.com サポートされているDB MariaDB MySQL PostgreSQL SQLite SQL Server DBへのアクセス方法 　・DB ファサード $users = DB::select('select * from users where active = ?', [1]); 　・クエリビルダ $users = DB::table('users')->where('active', $isActive)->get(); 　・Eloquent $users = User::where('active', $isActive)->get(); ここでは、「LaravelではEloquentを利用するの良いだろう」という意見が挙がりました。 「様々なブログでも紹介されている」とう点や、「 SQL を知っていると直感的で分かり易い」といったコメントが挙がっていました。 Symfony symfony.com Doctrine(ORM)を使用 composer require doctrine maker インストールが完了すると .env ファイルにデータベースへの接続設定に関する項目が書き足される DATABASE_URL の箇所を接続するデータベースに合わせて書き換える DATABASE_URL=mysql://db_user:db_password@127.0.0.1:3306/db_name php bin/console doctrine:database:create エンティティクラスを作成する symfony console make:entity hoge CakePHP SELECT文の実行 <?php use Cake\Datasource\ConnectionManager; $ connection = ConnectionManager :: get ( 'default' ) ; $ results = $ connection -> execute ( 'SELECT * FROM articles' ) -> fetchAll ( 'assoc' ) ; INSERT文の実行 <?php use Cake\Datasource\ConnectionManager; use DateTime; $ connection = ConnectionManager :: get ( 'default' ) ; $ connection -> insert ( 'articles' , [ 'title' => 'A New Article' , 'created' => new DateTime ( 'now' ) ] , UPDATE文の実行 <?php use Cake\Datasource\ConnectionManager; $ connection = ConnectionManager :: get ( 'default' ) ; $ connection -> update ( 'articles' , [ 'title' => 'New title' ] , [ 'id' => 10 ]) ; DELETE文の実行 <?php use Cake\Datasource\ConnectionManager; $ connection = ConnectionManager :: get ( 'default' ) ; $ connection -> delete ( 'articles' , [ 'id' => 10 ]) ; Slim なし 最後に 今回は PHP の主要な フレームワーク について、様々な観点から見比べてみましたがいかがでしたでしょうか？ どの フレームワーク にも様々な特徴がありますが、チーム特性や作成するアプリケーションによっても採用する フレームワーク は変わってくると思います。 基本的な部分についてはどれも使い方は同じで、感覚的に使えるようになっているため、実際に触りながら色々と比べて見ると面白そうですね。 ShowNoteの方には「バリデーション」や「 マイグレーション 」についての比較も行っていますので是非ご覧になってください。 hackmd.io 「 PHP TechCafe」では今後も PHP に関する様々なテーマのイベントを企画していきます。皆さまのご参加をお待ちしております。 connpass.com エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、主催イベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

元々CMS（コンテンツ・マネジメント・システム）というのはWebサイト構築に使われてきました。有名なところとしてはDrupal、WordPress、MovableTypeなどがあります。いずれもHTMLを出力するもので、ブログや一般的なWebサイト構築に使われています。 そんな中、最近ではAPIを公開し、HTMLを使わないタイプの利用が進んでいます。HTMLを全く出力しない、ヘッドレスCMSと呼ばれるタイプのCMSも出てきています。 配信先がWebに限らなくなってきた このようなAPI化が進む大きな要因としては、コンテンツの配信先がWebに留まらなくなってきたことが挙げられます。特に大きいのはスマートフォンアプリでしょう。数年前であればWebViewを使ってヘルプやよくある質問、リリース情報などを配信するケースもありましたが、最近ではAPIを使うことでよりネイティブな表示を行うケースが増えています。 Webとアプリ、両方に同じ情報を発信したい時にもCMSをベースにすると便利です。元々Web向けの機能はありますので、追加としてアプリをサポートできるようになります。管理画面が同じなので、運用コストも増えません。 システム連携の重要性 これまでCMSを使いつつEコマースやコミュニティサイトを立ち上げたいと思ったら、プラグインに頼る方式になっていました。しかしプラグインが専門のソフトウェアに敵うケースはなかなかありません。やはり機能の不足感を感じてしまうでしょう。 そうした中でAPIを用いた連携であれば、専門のソフトウェアとCMSを柔軟に連携させられるようになります。すでに数多あるEコマースシステムを置き換えるようなプラグインを開発するのではなく、Eコマースシステムが不得意とするCMS機能についてだけ連携するような形です。お互いの得手不得手を補い合うことで、より魅力的なサービスが実現できます。 便利な管理画面 CMSの魅力と言えるのが管理画面です。コンテンツをただ書くだけでなく、承認機能であったり、メタ情報の追加などもできます。公開日時の設定やパスワードロックなども可能です。こうした機能をイチから作るのはとても大変で、APIを介してCMSを利用することで手軽に手に入るようになります。 APIを使う場合、テーマやウィジェットなどのUI部分については利用できなくなります。柔軟性を得られる一方でCMSで元々提供されていた便利な機能も幾つか使えなくなります。そうした点に留意しつつ自社システムに組み込んでいく必要があるでしょう。 異なるUXへの対応 前述のWebとアプリの違いはもちろん、スマートフォンとデスクトップのWebブラウジングもまた異なるユーザ体験が求められます。スマートフォンではSPA（シングルページアプリケーション）のように動くものが求められたり、より途切れない画面遷移が理想とされます。 そうしたデバイスの違いはレスポンシブWebデザインによってUIで埋めることはできます。しかしクリックやタップなどの違いを吸収するのは大変です。無理にWebでアプリのような動きを再現するのではなく、APIによってコンテンツを各デバイスに配信し、表示やUXは各デバイス毎に最適なものを実装するのも一つの解決策となってきています。 CMSがAPI化されることで、よりコンテンツにフォーカスした運用が求められるようになります。また、CMSでWebサイトを構築するという従来の目的に留まらず、アプリや他のシステム向けのコンテンツ配信など幅広く活用が考えられるようになります。CMSを画像や動画、テキストなどのアセット管理に使ったり、コンテンツ配信元にしたシステム構成を考えると、従来よりも可能性が広がっていくのではないでしょうか。

去る12月3日、渋谷の21cafeにて Enterprise APIs Hack-Night #2 が開催されました 。今回はそのレポート記事になります。 Enterprise APIs Hack-Night #2 - connpass Office 365 を中核としたこれからの API 戦略 登壇者：日本マイクロソフト株式会社 テクニカル エバンジェリスト 松崎 剛さん Microsoftでは多くのWebサービスを提供していますが、今回はその中でもOffice 365に関する話になります。Office 365ではExtensibility、Remote API Accessがありますが、今回はRemote API Accessについてしょうかいします。技術的にはOAuth2とRESTfulを使っている。 大事なキーワードはOpenness。JavaScriptがあればVisual Studioを使わなくても開発できます。言語にも依存しないので、.NET以外の言語でも開発できます。 もう一つの戦略はクロスデバイス。最近はApple、Androidを優先して開発しているくらいです。昔はWindowsを優先していましたが、iOSやAndroidの上でも自分たちの製品を使ってほしいと考えています。 今後のOffice 365 APIがどうなっていくかについて、まず現状から説明します。 OneDrive SharePoint Exchange Active Directory これらはすべてRESTfulなAPIが用意されています。Azure ActiveDirectoryがすべての認証を司っています。ここだけ取り出して使うことも可能です。ビジネス向けとして、管理者がOKを出したら従業員の方は、わざわざ一つ一つの機能に許可を出さなくてもOAuth認証だけで機能を使えるようにしています。 そして今後についてですが、1週間前に発表したのがUnified - Microsoft Graphです。これまで各APIはエンドポイントがばらばらで、権限も個別に分かれていました。ファイルを上長にメールするなどといったら、各APIにアクセスしないといけない状態で、そのファイルのある場所によって各APIの許可をもらう必要があります。 ユーザが選択したファイルのプレビューを出といった操作をしようとした場合、Exchange、SharePoint、OneDriveの各パーミションを取っておかないといけませんでした。Graphはエンドポイントを一つにし、横の製品間の横断をできるようにします。 Unifiedにはもう一つの側面があります。ビジネスとコンシューマ用APIの統合です。例えばMSにはOneDriveが2つあります。一つは単なるOneDriveで、もう一つはOneDrive for Businessです。同様にSkypeもあります。 今後、すべてAPIのエンドポイントを統一（graph.microsoft.com）していきます。ただし、これはコンシューマとビジネスが一緒になるという意味ではありません。for Businessは今後も残っていきます。APIのエンドポイントを一つにしていくだけです。アプリを一つを作っておくと、もう一つ（ビジネス）にも対応できるようになります。 さらにソケット型のサードパーティ統合が行われます。例えばOffice 365のアプリランチャーの画面に認証したアプリが出るようになります。そしてアプリから簡単に機械学習などのAzureの機能が使えるようになります。その結果、あなたの組織はどれだけ会議をしたかなどをビジュアル化することができたり、セールスフォースなどからデータを出せるようになるのです。 最後にSkype Developer Platform。今はSkypeのオンプレ版しかありません。今後REST APIを出します。音声通話、ビデオ通話に関するAPIを含まれます。JavaScript SDKを出すので簡単に使えるようになるでしょう。 トレタ × Yahoo! JapanのAPIによる提携の話 登壇者：増井 雄一郎 さん Yahooが先日リリースした空席レーダーはトレタのデータを使っています。今から歩いて5分のところにある30人入れる店を探せるようなアプリです。 トレタCEOの中村は元々レストランを経営しており、実際に予約台帳を手書きでやっていました。この予約台帳はレストランの生命線であり、これをデジタル化しようとしているのがトレタになります。 提携の話が出たきっかけは、CEOがたまたまYahooの人と話をしたところからです。Yahooも元々Yahoo予約をやっていたのだけれど視点が違うという認識でした。これまでの問題は、予約サイトから予約があると、紙の台帳に反映して、各予約サイトにも反映するという大きな作業があった。そのため、飲食店側が面倒で使うのを嫌がりました。トレタは予約台帳システムなので、受け口は電話でもAPI経由でもOKというのが大きなポイントです。 そしてYahooとトレタで予約を軸に毎週ペースで会議を重ねて、APIのフォーマットを議論していきました。お互いサービスの初期設計の段階から提携できる形に設計を行っていたので話はスムーズでした。例えばトレタは予約は埋まる視点、Yahooは予約が空いているところという視点で、側面がまったく異なるのです。 今の時代、すべて自分たちでやるというのは無理があります。トレタではレジの会社のAPIとつなごうと考えています。そのためには外部連携することを前提とする必要があります。また、先にAPIの実装が終わっているというのがポイントです。大手と同時にやると力関係が働くので注意が必要です。 さらに本体のコアバリュー以外はAPIとしておく必要があります。また、オープンスタンダードを採用するのもポイントです。他社では独自の仕組みを無理押ししてくると聞きますが、トレタではOAuth2を使っている。標準技術を使っているので繋ぎこみの話がとても早く済みます。 最後に、大手との提携になるとPマークの取得、セキュリティ監査が必須になります。このコストは意外と大きいので、セキュリティチェックすることを前提に、チェック表などを作っておけば良かったと今ではかんじています。 提携先の対応速度は優先度次第です。トレタも今は4000店舗を越えて話がしやすくなっています。リリースしたばかりだと優先度が上がらないので、実績をあげるのが大事です。また、トレタは飲食店の代弁ができるといった立ち位置だったので相手も話を聞いてくれました。今後、スタートアップは大手と組んでいかないといけないと感じています。そんな時、大手に旨味をとられるのではないか、潰されるのではないかと心配してもしかたがありません。大手はリソースがあるので、やろうと思ったら提携せずともできてしまいます。なので自分たちの持ち味をいかさないといけなければならないのです。 「データの力を、まちの力に」〜UDC2015の取り組みとオープンデータ・プラットフォームDKANの活用〜 登壇者：東京大学空間情報科学研究センター（CSIS） 瀬戸 寿一 さん 登壇者：ANNAI 太田垣 恭子 さん 私たちはUrban Data Challenge 2015というプロジェクトを行っています。これは1年間を通して地域課題を解決していくプロジェクトです。地域課題というのは短い期間で結果を出すのは難しいと感じています。例えば札幌の保育園マップをベースとして、同様の動きが東京などに広がっています。 私たちは全国20拠点を設けていて、通年でワークショップで行っています。金沢では毎月ワークショップをやっているくらい活発です。また、社会性ある活動とあって、データパートナーが多いです。国立国会図書館、NAVITIME、オープンガバメント推進委員会などです。 オープンデータについては2014年は2500件でしたが、2015年は10457件と4倍以上になっています。ただし、日本のオープンデータは自治体のサイトに埋め込まれているため、手作業で収集しなければなりませんでした。中にはWeb APIでデータをオープンにしている自治体もゼロではありません。流山市、会津若松市はAPIを提供中です。 このオープンデータを支える仕組みとして知っておいて欲しいのがオープンデータポータルである、そのオープンソース実装がdkanです。システムはDrupalを使っています。DrupalはWebアプリケーションプラットフォームとして知られていて、有名なところではホワイトハウスがあります。政府自治体で24%のシェアを誇っており、オーストラリア政府はすべてDrupalにしようとしているくらい認知度があります。 そしてDrupalはAPI連携に強いCMSであり、REST対応にも対応しています。例えば以下のようなプラットフォームと連携できます。 他のDrupalサイト Android iPhone その他 オープンデータとは誰でも自由に使えるデータ置き場のことです。再利用、再配布も許可されています。そのため、使いやすいことが大事です。外部連携やAPIで取得できたり、各データのURIがあったりといった具合です。ただ、自治体の担当者レベルではCSV公開ですら大変なのが実状です。そんなレベルではデータ検索がしたいニーズはあるのですが、作るのは大変だったりします。 そういった機能をパッケージングしたのがdkanです。Drupal拡張なのでモジュールも利用できます。ECも大丈夫です。似たようなものにCKANもあり（Python）、dkanはCKANとのAPI互換となっています。他にも組織による権限分配に対応していて、自治体のような組織でもワークフローが構築できます。データはSolrを使って検索できます。 ロシア政府データポータルもdkanでできています。表形式で出したりグラフ化、地図化できます。データは一般公開なのか、ユーザ登録必須とするかなど自由に設計できます。 品質APIのご紹介とniconicoでのトライアル事例 登壇者：NTTネットワーク基盤技術研究所 木村 拓人 さん QoEとはユーザ体験の品質のことで、今回は品質APIシステムがどういったものであるか紹介します。仕組みとしては次のようになります。 ユーザから視聴要求がくる 基地局、IPアドレスなどを受け取る 見たい動画に対して幾つかのレートを持っているので、品質APIに問い合わせる 品質APIは最適な動画の品質を返す ネットワーク品質に応じた配信を行うことで、再生停止発生率を著しく低減されられました。また通信データ量を20%下げることにも成功しました。 ユーザの視聴環境、動画配信条件を入力として、最適な配信条件を返す仕組みとなっています。 応用として、 通信前にAPIを叩くことで、通信状況が悪いためしばらくお待ちくださいといった案内が出せる 通信品質マップ などが考えられます。 第1回に比べて企業色を強く打ち出したイベントになっているかと思います。参加者の方の満足度も非常に高く、登壇の後の懇親会も大変盛り上がっていました。 次回は2月10日を予定しています。ぜひご参加ください！