毎回のログインが面倒なkeio.jp（klms)を、もっと快適に使えないか。
そんな思いから始まったKPassの開発は、思わぬ形で慶應大学のセキュリティポリシーという壁にぶつかることになりました。
Canvas LMSベースのklmsには公式APIが存在し、技術的には美しいUIを持つアプリの開発が可能です。
しかし、ログイン状態の維持という最も基本的な機能を実現しようとしたとき、大学のセキュリティ方針が立ちはだかりました。
今回の記事では、KPass開発における最大の技術的課題と、それに対する大学側の対応について振り返ります。
ぜひ最後までご覧ください。
KPassが生まれた背景──ブラウザを閉じるたびのログアウト問題
klmsの現状とユーザー体験の課題
klmsはブラウザを閉じるたびにログアウトされる仕様になっています。
授業資料を確認したい。
課題の提出期限を見たい。
そんなちょっとした用事でも、毎回ログイン画面からやり直しです。
慶應義塾の認証システムを経由する必要があり、この手間が日常的なストレスになっていました。
「爆速でklmsを開きたい」という発想
この面倒さを解消できないか。
そう考えたのがKPassのスタートラインでした。
ブラウザではなくアプリという形で、ログイン状態を保持したままklmsにアクセスできれば、ユーザー体験は劇的に向上します。
授業の合間、移動中、いつでもワンタップでklmsを開ける。
そんなアプリを目指して開発が始まりました。
Canvas APIとの出会い──公式の仕組みを活かす試み
Canvas LMSの技術基盤とAPI
klmsはCanvas LMSをベースに構築されています。
CanvasにはREST形式の公式APIが用意されており、ログイン状態であればコース情報や課題、成績などのデータを取得できます。
これを活用すれば、Webブラウザとは異なる、UI/UXに優れたネイティブアプリが実現可能です。
「綺麗なUI」を持つアプリの模索
公式APIの存在を知り、Canvas APIを叩けば、授業一覧や課題リストなどを取得できるのではと考えました。
それをアプリ側で整形して表示すれば、Webページよりも見やすく、使いやすいインターフェースが作れます。
あとはログイン状態をどう維持するか、その一点にかかっていました。
ログイン維持の壁──慶應のセキュリティ方針
外部からのログインは不可能
ここで最初の壁が現れます。
慶應義塾の既存認証システムでは、ログインしていない状態で外部アプリケーションから直接ログインすることができません。
OAuthのような外部認証フローも用意されておらず、アプリ側で独自にユーザー名とパスワードを扱うことも現実的ではありません。
セキュリティ上、当然の仕様です。
しかしアプリ開発者としては、この時点で大きなハードルとなりました。
アプリケーションパスワードという希望と挫折
klmsには「アプリケーションパスワード」という仕組みがあります。
設定ページから生成でき、外部アプリがAPIにアクセスする際に使用できるトークンです。
これならいけるかもしれない。
そう思いましたが、ユーザーが作成したアプリケーションパスワードは有効期限が1時間しかありません。
| 項目 | 内容 |
|---|---|
| 生成場所 | klms設定ページ |
| 用途 | 外部アプリによるAPI利用 |
| 有効期限 | ユーザー作成のものは1時間 |
1時間ごとに再生成を求めるのは、ユーザー体験として成立しません。
この方法も断念せざるを得ませんでした。
プロキシサーバーという解決策──そして禁止へ
セッション切れという最大の問題
アプリ内でログインできたとしても、セッションが切れればログアウトされます。
klmsはセッション管理が厳格で、一定時間操作がないとログアウトする仕様です。
つまり、アプリでログイン状態を保持していても、時間が経てば無意味になってしまう。
ここが最大の壁でした。
プロキシサーバー経由のアクセスという発想
そこで考えたのが、プロキシサーバーを介した仕組みです。
ユーザーがアプリでログインした後、そのセッション情報をプロキシサーバー側で保持します。
プロキシサーバーは1時間おきなど定期的にklmsのページをロードし直し、セッションを維持し続ける。
アプリ側はプロキシ経由でklmsにアクセスすることで、常にログイン状態を保てるという仕組みです。
| 仕組み | 役割 |
|---|---|
| ユーザー | アプリから初回ログイン |
| プロキシサーバー | セッション情報を保持・定期的にページロード |
| klms | プロキシ経由でアクセスされ、セッション維持 |
技術的には筋が通っており、実装も可能でした。
慶應ヘルプデスクへの問い合わせ
念のため、アプリリリース前に慶應のヘルプデスクに問い合わせました。
最初の返答は、予想外のものでした。
全否定です。
聞く耳を持ってもらえず、技術的な説明もうまく伝わらない様子でした。
おそらく「外部アプリが勝手に個人の慶應アカウントにアクセスする」という時点で、セキュリティ上の懸念を強く持たれたのだと思います。
再連絡
一部誤解されていた点もあったため、改めて丁寧に連絡しました。
プロキシサーバーの仕組み、セッション管理の方法、ユーザーのログイン情報をどう扱うか。
技術的な詳細を整理して伝えたところ、「技術的すぎるため、klmsの保守業者に問い合わせてみる」という返答がありました。
少なくとも、一方的に拒否されるのではなく、正式な判断を仰いでもらえることになりました。
1週間後の正式回答
約1週間後、正式な回答が届きました。
プロキシサーバーの使用は禁止。
理由は明確には示されませんでしたが、おそらくセキュリティポリシー上、外部サーバーを介した常時接続的なアクセスは認められないということでしょう。
Canvas APIを使うこと自体は問題ないが、ログイン状態を外部で維持する仕組みはNGという判断です。
唯一のログイン維持機能が全面否定された瞬間
正直、かなり落ち込みました。
プロキシサーバーの仕組みは、KPassにとって唯一のログイン維持機能でした。
それが全面的にダメだと言われたことで、アプリの根幹が揺らいだのです。
Canvas APIを使って綺麗なUIを作っても、毎回ログインが必要なら意味がない。
ブラウザと何も変わらない。
開発のモチベーションが大きく削がれた瞬間でした。
それでも
しかし、ここで終わりではありません。
プロキシサーバーが使えないなら、別のアプローチを考える。
Canvas APIの活用方法を見直しました。
WebViewという新たな道──方針転換の決断
アプリ内WebViewでセッションを維持する発想
プロキシサーバーがダメなら、別の方法でセッションを維持すればいい。
そう考えて辿り着いたのが、アプリ内のWebViewを使う方法でした。
WebViewとは、アプリ内にWebブラウザの機能を埋め込む技術です。
アプリ内でklmsにログインし、そのセッション情報をWebView内に保持する。
これなら外部サーバーを介さず、アプリ単体でログイン状態を維持できます。
プロキシサーバー不要のシンプルな実装
この方針転換により、システムはシンプルになりました。
仲介サーバーを用意する必要がなくなり、サーバー運用のコストやセキュリティリスクも回避できます。
ユーザーのログイン情報はアプリ内だけで完結し、外部に送信されることもありません。
| 比較項目 | プロキシサーバー方式 | WebView方式 |
|---|---|---|
| 外部サーバー | 必要 | 不要 |
| セッション保持 | サーバー側で管理 | アプリ内で完結 |
| セキュリティ | 外部送信あり | 端末内で完結 |
| 運用コスト | サーバー維持が必要 | なし |
技術的にも、大学のセキュリティポリシー的にも、この方法なら問題ありません。
開発言語の選択──FlutterからSwiftへ
当初はFlutterで開発していた
開発を始めた当初、使用していたのはFlutterでした。
FlutterはGoogleが開発したクロスプラットフォームフレームワークで、一つのコードベースでiOSとAndroidの両方に対応できます。
効率的に開発できる点が魅力でした。
SwiftでAndroid対応が可能になった転機
しかし、開発途中で状況が変わります。
Skipというツールや、Appleが公式にAndroid対応パッケージを公表したことで、SwiftでもAndroid対応ができる可能性が見えてきました。
SwiftならiOS特有のデザイン言語を存分に取り入れられます。
Apple製品のユーザーが多い慶應生にとって、ネイティブなiOS体験は大きな価値です。
iOS特有のデザインを活かす選択
最終的に、SwiftでのiOS開発を優先し、Android対応も視野に入れる方針にしました。
iOSのデザインガイドラインに沿った洗練されたUIを実現できる。
これがKPassの差別化要素になると考えました。
Flutterも優れたフレームワークですが、今回のプロジェクトではSwiftの方が適していると判断したのです。
AI駆動の爆速開発──1〜2ヶ月でのリリース
開発期間とAIツールの活用
開発期間はおよそ1〜2ヶ月。
この短期間で実現できたのは、複数のAIツールを活用したからです。
主に使ったのはCursorやGoogle Antigravityなどのソフトで、AIモデルとしてはGemini 2.0 Flash、Claude Sonnet 4.5がメイン。
これらを組み合わせて、爆速で開発を進めました。
AIと人間の役割分担
AIに丸投げしたわけではありません。
アプリの機能や仕様、セキュリティ設計などは自分で考えます。
その設計に基づいて、AIでアプリのベースとなるコードを書いてもらう。
細かな修正、リファクタリング、データベース設計は自分でやる。
| 担当 | 内容 |
|---|---|
| 人間（自分） | 機能設計、仕様策定、セキュリティ設計、細かな修正、リファクタリング、データベース設計 |
| AI | ベースコードの生成、繰り返し作業の効率化 |
この役割分担が、短期間での開発を可能にしました。
MVPとしてのリリース
まずは最低限の機能を盛り込んだアプリとして、12月19日にAppStoreにリリースしました。
完璧を目指すのではなく、動くものを早く出す。
ユーザーの反応を見ながら改善していく。
いわゆるMVP（Minimum Viable Product）の考え方です。
リリース初日の反響──想定を超える広がり
Instagramストーリーからの拡散
リリース初日、自分の本垢Instagramアカウントでストーリーを載せました。
慶應生向けのアプリとして、同じ大学の友人や知人に届けばいいと思っていました。
しかし、反響は想定を大きく超えるものでした。
24時間でフォロワー0→100超え
KPass公式Instagramアカウントのフォロワーは、自分の本垢と親しい友達だけで、リリース前はほぼ0。
それがリリースから24時間で100を超えました。
ストーリーのシェアやDMでの問い合わせも相次ぎます。
慶應生のコミュニティ内で、一気に情報が広がりました。
ユーザー数は24時間で350人超え
さらに、リリースから24時間でユーザー数が350人に達しました。
| 指標 | リリース24時間後 |
|---|---|
| 公式Instagramフォロワー | 0 → 100超 |
| ユーザー数 | 350人 |
プロモーション費用をかけたわけでもなく、ストーリー1つでここまで広がるとは思いませんでした。
klmsのログイン問題に困っていた学生がそれだけ多かったということでしょう。
ニーズを捉えていた実感がありました。
まとめ
KPassの開発は、技術的な可能性と大学のセキュリティ方針という現実の間で揺れ動きました。
プロキシサーバーという最初の解決策は禁止されましたが、WebViewという別のアプローチで道が開けました。
FlutterからSwiftへの言語変更、AIを活用した短期間での開発、そしてリリース初日の予想を超える反響がありました。
KPassはこれからも機能追加などのアップデートを進めていきます。
最後までご覧いただき、ありがとうございます。