ブラウザのURLバーにURLを入力して決定キーを押した時になにが起こるか

https://www.shonenjump.com/j/weeklyshonenjump/ を入力して決定キーを押した時になにが起こるか」 を調べた時のメモです。 自分用のメモなので読みづらいかもですがご了承ください。

※ 注意：以下の内容は誤りを含む場合があります。

目次

  1. ブラウザでの処理
  2. DNSによる名前解決
  3. TCP
  4. イーサネット/IPルーティング
  5. TLS
  6. HTTPレスポンスを受け取ったブラウザ

ブラウザでの処理

  1. 入力された文字列がURLかを判定 → URLでないならWeb検索
  2. 入力文字列がURLなら、文字列の解析
    • スキームの解析：about:、file:、http:、https:
    • キャッシュが存在するかの判定
      • if キャッシュが存在 && キャッシュが有効 then
        • キャッシュから読み出してブラウザに返却
      • else then
        • オリジンサーバに問い合わせ

  3. HTTPリクエストメッセージの作成

    • Chrome Devtools のNetworkタブからRequest Headers を確認すると、以下のようなHTTPリクエストメッセージが作成されていることがわかる
      リクエストヘッダー
    • :authority、:method、:path、:scheme などの疑似ヘッダーがあるので、HTTP/2が使われているぽい
      • DevtoolsのNetwork panelをご活用いただいてるとおもうのですが、表の見出し行を右クリックいただくと "Protocol"列を追加できます

  4. 作成したHTTPリクエストメッセージを送信する

    1. その前に、WebサーバのIPアドレスがわかっていないので、まずは取得する → 次章へ

DNSによる名前解決

DNSサーバにドメイン名を問い合わせ、サーバの「IPアドレス」を取得したい

  • dig コマンドを使えば確認できる

      dig +noedns www.shonenjump.com

  ; <<>> DiG 9.10.6 <<>> +noedns www.shonenjump.com
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 331
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

  ;; QUESTION SECTION:
  ;www.shonenjump.com.        IN  A

  ;; ANSWER SECTION:
  www.shonenjump.com. 300 IN  A   202.218.223.232

  ;; Query time: 118 msec
  ;; SERVER: 172.23.0.1#53(172.23.0.1)
  ;; WHEN: Wed Jul 03 23:29:16 JST 2024
  ;; MSG SIZE  rcvd: 52
    • IPアドレスは 202.218.223.232 らしい
    • DNSクエリは ;www.shonenjump.com. IN A っぽい
  • ローカルマシンのDNSキャッシュを確認してみる
    • Windowsだとコマンド一発で確認できた
      ipconfig/displayDNSの実行結果
    • ❓TODO: Mac環境での確認方法も知りたいな
    • ローカルマシンのDNSキャッシュに www.shonenjump.com がない場合、DNSリゾルバに問い合わせる
  • DNSリゾルバの動作
    DNSリゾルバの動作
    • キャッシュ：毎回上位のDNSサーバに問い合わせていては時間がかかるので、ドメイン名-IPの対応づけをキャッシュしている
    • 💬 再帰問い合わせという設計にしている理由は、世界中の全てのWebサーバのドメイン-IPアドレスの対応付けを、1つのDNSでしてしまうと大変。なので、ドメインごとに階層化すればよいという考え方
  • dig +noedns で確認したDNSクエリは www.shonenjump.com. IN A だったが、shonenjump.comの権威DNSサーバが受け取るクエリも↑と同じ？

TCP

サーバに接続し、アプリケーションから依頼されたメッセージを小さな断片に分割してサーバに送信したい

この時、エラーでパッケットが消えてしまうことを想定し、分割した断片がサーバーに届いたかを確認、届かなかったら再送する

  • 参考：RFC 9293 - Transmission Control Protocol (TCP) 日本語訳

  • アプリケーションから見たソケット通信の流れ

      // 名前解決
  <メモリ領域> = gethostbyname("www.shonenjump.com");

  // 準備
  <ディスクリプタ> = socket(<IPv4を使用>, <ストリーム型>, ...);

  // 接続
  connect(<ディスクリプタ>, <サーバのIPアドレスとポート番号>, ...);

  // 送信
  write(<ディスクリプタ>, <送信データ>, <送信データ長>);

  // 受信
  <受信データ長> = read(<ディスクリプタ>, <受信バッファ>, ...);

  // 切断
  close(<ディスクリプタ>);

  • connectは、3 Way Handshaking 方式で確立される

    TCP 3-way handshaking

  • 接続 終了時

    TCP 接続終了

  • TCPヘッダのフォーマット

    各フィールド ビット数 各フィールドの説明
    送信元ポート番号 16 bit 送信元のポート番号の値。
    宛先ポート番号 16 bit 宛先のポート番号の値。
    シーケンス番号 32 bit 送信したデータの順序を示す値。「相手から受信した確認応答番号」の値。
    確認応答番号 32 bit 確認応答番号の値。「相手から受信したシーケンス番号」＋「データサイズ」。
    データオフセット 4 bit TCPヘッダの長さを示す値。
    予約 3 bit 全ビット「0」が入る。将来の拡張のために用意されている。
    コントロールフラグ 9 bit NS、CWR、ECE、URG、ACK、PSH、RST、SYN、FINの9ビットで構成。これらのビットは「1」の値が入る（フラグを立てる）場合に意味をなす。
    ウィンドウサイズ 16 bit 受信側が一度に受信することができるデータ量を送信側に通知するために使用される。送信側は、この値のデータ量を超えて送信することはできない。
    チェックサム 16 bit TCPヘッダとデータ部分のエラーチェックを行うために使用される値が入る。
    緊急ポインタ 16 bit コントロールフラグのURGの値が「1」である場合にのみ使用されるフィールド。緊急データの開始位置を示す情報が入る。
    オプション 可変長 TCPの通信において、性能を向上させるために利用する。例えばTCPコネクションの際に、MSSを決定するために使用される。
    パディング 可変長 TCPヘッダの長さを32ビットの整数にするために詰め物（Padding）として空データの「0」の値を入れることにより調整する。

  • コントロールフラグの詳細

    ビット 値が「1」である（フラグが立っている）時の意味
    NS ECN-nonce 輻輳保護を示す。
    CWR 輻輳制御ウィンドウ縮小（Congestion Window Reduced）を示す。
    ECE ECN-Echo を示す。SYNフラグがセットされている場合、ECNが利用可能であることを意味する。
    URG 緊急に処理すべきデータが含まれていることを示す。
    ACK 確認応答番号のフィールドが有効であることを示す。コネクション確立時以外は値が「1」。
    PSH 受信したデータをバッファリングせずに、即座にアプリケーション（上位）に渡すことを示す。
    RST コネクションが強制的に切断されることを示す。何らかの異常を検出した場合に送信される。
    SYN コネクションの確立を要求することを示す。
    FIN コネクションの正常な終了を要求することを示す。
    • 💬 TCPフラグ値のLSB3bit → RST、SYN、FIN
  • TCPチェックサムの計算範囲（ピンク部分）

TCPチェックサムの計算範囲（ピンク部分）

  • ✍️ tcpdump でTCP通信をキャプチャして出力できる

イーサネット/IPルーティング

  • IPルーティングの仕組み
    • まず端末からL2 segment内のルータに投げる
      • 宛先がL2 segment内なら直接送信できる
      • 各ルータは自分が直接接続しているネットワークなら送れるが、それ以外は知らない
        • 今回のケースはLAN内ではない
        • その場合、とりあえずえデフォルトゲートウェイ（今回は gw.cysec.ritsumei.ac.jp）に送っている
    • デフォルトゲートウェイに送る際、送り元IPアドレス 192.168.100.18 はプライベートIPアドレスなので、グローバルIPに変換する必要がある
      • それをするのがNAT君
      • もし、プライベート↔︎グローバルIPの相互変換をしないままISPルータに送ると破棄されてしまう
    • デフォルトゲートウェイを経由してISPルータまで届けられたとして、どうやってさらにその先のネットワークに送り届けられるか？
      • IPルーティング：ルータ間でどこにどんなネットワークがあるのかを情報交換する仕組み
      • ルーティングテーブル：宛先IPアドレス→送り先ゲートウェイIPアドレスへの変換表
        • 実際にはネットワーク部分だけ見る
        • すべてのIPアドレスを経路表に登録して完全一致するかどうか調べてたら大変
        • ルーター同士のルーティングテーブルの交換は、BGPなどのプロトコルがある
    • ✍️ netstat -rn でマシンのルーティングテーブルを表示できる
  • 問

  • 問：端末は、192.0.2.10というIPアドレスを宛先とするIPv4パケットを、ルータに送信します。しかしルータのIPアドレスは192.168.0.1です。どうやってルータに送信するんでしょう。

  • 問： 192.168.0.100発、192.0.2.10宛のIPv4パケットを受け取ったルータは、上流のISP(インターネットサービスプロバイダ)にパケットを転送します。しかしそのまま転送すると、ISPルータはこのパケットを破棄してしまうと思います、それはなぜでしょう。ルータは、転送する前に端末から受け取ったIPパケットに対してどういう加工を行いますか。

  • 問：ISPルータは、家庭ルータから受け取ったパケットを、別のルータに向けて転送します。この際、ルータはパケットの加工をおこないますか？おこないませんか？(パケットのヘッダは、ルータが受け取ったパケットとルータが次ルータに送出するパケットで同じでしょうか？)理由とともに述べてください
    • TTLは変更しないとネットワーク内での無限ループが発生してしまう。TTLの変更に伴いIPヘッダチェックサムも再計算しないといけない。送信元IPアドレスや宛先IPアドレスに関しては変更しなくてもよい
  • 問：ISPルータは、192.0.2.10サーバに直接繋がっておりません。複数のルータを経由して、最終的に192.0.2.10へパケットが到達します。また、ISPルータは、複数のルータと相互接続していると思います。どのルータにパケットを転送するか、どう決めているんでしょう。
    • ISPルータは、宛先IPアドレスに基づいてルーティングテーブルを参照し、最適な次ホップアドレスを決める
    • ルーティングテーブルの作成にはBGPを利用し、他のルータと経路情報を交換することで作成する

TLS

  • https://www.shonenjump.com/j/weeklyshonenjump/ では https とある通り、TLSプロトコルによりセキュアな接続が行われている
    • 通信の暗号化
    • 改ざん検知
    • 通信相手の認証
      1. クラウアント：デジタル証明書を要求
      2. サーバ：デジタル証明書を送付
      3. クライアント：デジタル証明書の情報から Webサーバの身元と安全性を確認
        • Chromeでは証明書ビューアから閲覧できる
          デジタル証明書ビューア

HTTPレスポンスを受け取ったブラウザ

参考

https://bookplus.nikkei.com/atcl/catalog/07/P83110/

https://www.slideshare.net/slideshow/url-120966707/120966707

https://browserbook.shift-js.info/

セキュリティキャンプ2024 ネクスト 参加記

2024年8月12日～8月17日に開催されたセキュリティキャンプ2024にネクスト受講生として参加してきました。 今年のネクストは応募倍率14倍だったらしく、拾ってもらったからにはと気を引き締めて頑張りました。 本ブログでは、いくつか受講した講義をピックアップして内容および感想を紹介します。

www.ipa.go.jp

共通講義

K1『ゲームセキュリティの歴史』

本講義では、ゲームにおける不正の歴史と現状を振り返り、どのような技術的対策が行われ、どのように法律が変化してきたかについて解説いただきました。スーパーファミコン、ニンテンドーDSなど多くのゲーム機では、マジックコンピュータ（通称マジコン）という、ゲームソフトを複製する、あるいは公式に提供されていない機能を実現するハードウェア装置が多く出回りました。不正コピーの被害はゲームだけでなく商用ソフトウェアも受けており、「一太郎の解説本が一太郎の10倍売れた」というエピソードはなかなか強烈でした。歴史を通して不正コピーとチートとの攻防はどこまでいってもいたちごっこだなぁという印象でした。防御側の技術的な対策としては、認証や暗号化、難読化により複製をしにくくする方法、複製されたら環境が壊れるようにする方法（私的制裁なので開発者倫理として疑問）などの対策が紹介されました。ただ、攻撃側は、機器が手元にある分いくらでも解析できるため有利です。そのため、技術だけではなく法律で対応しようとしていて、例えば、著作権法や不正競争防止法でコピーガード回避を禁止しています。ググってみると、実際に2011年頃にマジコン販売が不正競争防止法の改正により刑事罰対象になっていました。最近では、FPSなどのオンラインゲームでのチートも被害が拡大しています。私の研究室では、オンラインゲームのチート対策に関する研究が行われています。TEEや準同型暗号といった暗号化技術で防ごうという手法にはなりますが、オーバーヘッドが大きくてFPSなどのリアルタイム性が必要なゲームへの適用はまだ現実的ではありません。このように、ユーザビリティを損なうという意味でも技術的な対策には限界があります。そのため、マジコン販売が法改正により禁止されたように、オンラインチートも法改正により刑事罰対象にならないのか疑問に思っています。と、思って調べてみたら、電子計算機損壊等業務妨害罪に問われた事例があるみたいでした。さいごに、ゲームセキュリティの分野の課題として、刑法罰になる境界や倫理上問題ない境界、合法である境界があいまいであるが故に「技術的にできる⇒やっていい」思われてしまっているのではと思いました。

T1『日本発のサイバー技術の造り方』

本講義では登大遊先生から、日本が世界に通用する高品質なサイバー技術を生み出す方法について解説いただきました。その方法論について登先生が重要視されているなと感じたのは、①実験的で自由な試行錯誤を許容する環境を設けること、②システムソフトウェア領域とネットワークシステム領域において知見のあるICT技術者を育成することでした。②に関して、クラウド人材がクラウドを作る人ではなくクラウドを使う人というのはいかがなものか、というご指摘はWeb屋の私自身とても刺さるものがありました。。。

そんな中、今回のセキュリティキャンプ ネクストのテーマは「基盤技術の魅力」とある通り、社会基盤〜アプリケーション基盤〜物理基盤といった基盤技術に触れられました。

ネクスト専門講義

N2『C++ ライブラリ開発』

本講義では、Siv3Dの開発者である鈴木さんから、可読性とユーザーフレンドリーな設計を兼ね備えた高性能ライブラリを、C++23を使って開発する方法について学びました。具体的には、二次元座標を表すPoint class、RGBで色を表すColor class、ファイルへの読み書きを行うBinaryFileReader/Writer class、これらを利用して画像を表すImage class、Image classをさらに拡張してビットマップを表すBMP classを実装しました。普段C++を書いていてバグの原因特定が非常に難しいという感触があって、なんとかならないものかと感じていましたが、C++23の構文や設計パターンを用いることで、堅牢で可読性のあるプログラムが作れることが実感できました。例えば、pImplパターン（pointer to implementation）やconstexpr構文、はかなり印象的でした。C++の言語仕様は後方互換性を保ちつつ、新たに構文を追加することで、より堅牢な記述を可能にすることを目指ししています。だからこそ、こういった新しい構文を継続的に学んでいくことが大切だと感じました。

N3『DNSの運用における潜在的リスクと対処について』

本講義では、MyDNS.JPの開発者である鏑木さんから、昔話編としてアマチュア無線機の話題、本編としてダイナミックDNSを運営する上での苦労や、ダイナミックDNSの技術的知見について解説いただきました。昔話編で印象的だったのは、組込みシステムではよく使われている「状態遷移表を用いた設計手法」でした。具体的には、横軸に示した状態で 縦軸に示した事象が起こったときに、セルに示した処理が実行される、という表現方法です。何が嬉しいかというと、状態遷移が複雑になった際に、単にif文条件分岐で実装しようとするとプログラムが非常に複雑になる一方、状態遷移表だと設計段階で品質を担保することができます。そんな昔話も交えつつ、MyDNSの運用編では、時代の流れに合わせてIPv4/IPv6デュアルスタック対応したり、サーバメンテナンスのためにマネタイズをしたりなどのお話をお伺いし、サービスを独自運用する魅力や苦労を知ることができました。

N4『Content Delivery Network を自作してみよう』

本講義では、前半で仮想環境内でのCDN構築、後半で実機を用いたネットワーク構築演習を行いました。前半講義がとても印象的で、GSLBの動作原理を学んだのち、GSLBのクエリ処理ロジックを実装する演習を行いました。 地域から一番RTTが最も短いPoPのIPアドレスを返すクエリや、GeoIPによる地理的に最も近いIPアドレスを返すクエリを実装した人がいました。ちなみに私は、IP Hashに基づいたルーティングクエリを実装してみました。これは、同じユーザを常に同じPoPにルーティングさせることで、セッションに一貫性を持たせたい、という意図で実装しました。この実装に対し講師の上野さんからは、DoS攻撃に対する対策としても有効で、DoS攻撃によってPoPを全滅させられる危険性を軽減できるというフィードバックをいただき、大変勉強になりました。

事前課題で構築したL4LBの構成図

N6『TCP/IPプロトコルスタック自作入門』

本講義ではまず事前課題として、KLab Expert Camp「TCP/IPプロトコルスタック自作開発」を参照しながら、教育用のプロトコルスタック「microps」を実装しました。具体的には、ネットワークデバイスの登録→Ethernetフレームの組み立てと送受信→ARP→IP/ICMP/UDP/TCPを処理するプログラムを実装しました。ただし、この段階ではカーネル空間ではなくユーザ空間で動作する実装となります。講義では、実装したプロトコルスタックを教育用OSのxv6のカーネル空間で動作するよう移植しました。私の動作環境について補足すると、事前課題はMacOS > Ubuntu DevContainer (Docker) > microps、講義ではMacOS > Ubuntu DevContainer (Docker) > QEMU > xv6 > micropsという環境で作業を進めました。事前課題のmicropsの実装では、コード量が大きくなるにつれて各コンポーネントの構成や呼び出し関係のフローを把握するのが難しく感じたので、個人的に以下のような図を書いて整理していました。

microps構成図
micropsフローチャート

実際に手を動かすことで感じた面白かった点として、ICMPの実装は印象的でした。IPとICMPはどちらもインターネット層で同階層のプロトコルで、プロトコルスタックとしても同階層として別々に実装するのかなと予想して読み進めてみると、そうではなく、ICMPをIPの上位プロトコルとして見立てて実装していました。ICMPヘッダのパケット構造は「MACアドレス>IPヘッダ>ICMPヘッダ>データ」なので言われてみればそらそうなんですが、実際に実装しようとしてみないと気づかなかった点でした。また、実装で難しかったのはTCPの状態遷移あたりの処理でした。これはTCPがややこしいというよりかは、状態遷移によってif文条件分岐が複雑化したことが混乱の要因でした。今回はC言語での手続型な実装でしたが、これが例えば前述した状態遷移表や、デザインパターンでいうところのState patternで実装してみるとどうなるのかも気になっています。

謝辞

セキュリティキャンプ開催にあたりご尽力いただいた運営関係者のみなさまに心より感謝申し上げます。 このような貴重な機会をいただき誠にありがとうございました。

セキュリティ・キャンプ2024 ネクスト 応募課題晒し

応募課題はこちらに記載されています。 www.ipa.go.jp

選考のポイント

基本として、加点法で判断します。 自身の技術力ややってきたこと、発信してきたこと、何ができるかといったことなど、アピールしたい点を存分に記述してください。 多く書くことにより、「文章が長過ぎる・まとまりが無い・重複している・冗長」などとして減点するようなことはありません。失敗した経験や落選の結果を書くことや、「文章が洗練されていない」「誤字脱字がある」などによる減点もありません(文章や作文のテストではありません。内容を見ます)。アピールをいっぱい書いて、得をすることはあっても、損をすることはありません。自身がアピールしたいことを思い付くままにいっぱい書いて、アピールしてください。 いかにやる気があるか、参加できたらいかに頑張ることができるか、ということを「示して」ください。「やる気があり、今までこうしたことをやってきています」「このようにいままでずっと手を動かしてきています」「こういったものを作ったことがあります」「今までこんな活動を継続してきています」ということを書くといいでしょう。それが、やる気を証明することになります。 課題については、課題が解決できたかどうかや正誤で判断するのではなく、いかに自身で疑問を持ち課題設定するか、その課題を解決しようとする過程や未知のことにどのように取り組むか、新たなことに挑戦しようとする姿勢を見ます。 このため課題は解決できなくても構いませんし、正答にたどりつけなくても構いません。課題に対する正答を求めているわけではありません。途中経過でも構いませんし、自分なりの考えでも構いませんので、いかに取り組んだか、難しい課題にこのように取り組んでこの辺りまではわかった、自分なりにこう考え、こういうことを調べた・試した、自分はこう考えこう思ったという、その過程を書いてください。自身のできる範囲で課題設定して回答するのでなく、ぜひ今まで知らなかったものに挑戦して、その挑戦の過程を書いてみてください。その結果正答でないとしても、それは挑戦しているためとして判断します。 手を動かしてみてください。ネット検索で調べたことを張り付けるだけではなく、本当にそうなのかという疑問を持ち、自分で手を動かして、見て、試し、調べ、確認し、本当にそうなのかと深堀りして考えてみてください。ネット検索で出てきたことは、はたして本当なのでしょうか︖深堀りして理解し納得できているでしょうか︖疑問点や矛盾は無いでしょうか(矛盾があるとしたら、その原因はどこでしょうか)︖自分の眼や手で確認したでしょうか︖他人に説明できるでしょうか︖そして、そうしたことを書いてください。課題解決に対する、そのような姿勢を見ます。

加点法でアピールになりうることは全部書けとのことだったので、今まで学んできたことをできるだけダンプしてみました。 今までの執筆ブログ、論文、就活でのエントリーシート、開発プロダクトのREADMEなどなどを参考にしながら、そういえばあんなことやったなぁと言いながら書き進め、気づけば16,000字超に。 公開にあたり内容は一部伏字にしています。

1. あなたに関する問い

あなたは今までどのようなことをやってきましたか．どのようなことができて，どのようなことが得意で，どのようなことに自信がありますか． どのようなものを作りましたか．どのような情報を発信してきましたか． どのようにしてそうしたことをやってきましたか．なぜ，そのようなことをやってきましたか．やってきてどう思いましたか． 参加できた場合，セキュリティ・キャンプ ネクストにどのようなことを期待し，どのようなことをやってみたいですか．

CGシミュレーションに初めて触れたことが私のコンピュータを学ぶきっかけとなり、その後ネットワークセキュリティ、構文解析、Web開発といった分野で知見を深めてきました。学習過程についてまとめた図は、下記リンクからご覧ください。 本回答では各分野での経験、および今後の目標について述べます。

CG編

アートサイエンスとしてのCGシミュレーション

高校生の頃、科学部にて「アナモルフォーズ」や「計算折り紙」をテーマに活動していました。 前者について、「アナモルフォーズ」とは、ゆがんだ絵を円筒型の鏡に投影することで元の正常な絵が見えるというアート技法です。 科学部ではアナモルフォーズ作品を通して、光の性質を知ってもらおうという活動をしていました。 その一環で、光の通り道を可視化するため、Excelで光の進み方を計算し、Graph-Rという3次元グラフ作成ソフトを用いて点群データを描画する仕組みを構築しました。 一連の成果を発表するため、関西地区最大の科学イベントである「青少年のための科学の祭典大阪大会・サイエンスフェスタ2017」にて発表を行い、奨励賞を受賞することができました。 その後、活動テーマは変わり、折り紙と数学の関係性をテーマに活動していました。 その中で、三谷純教授（現筑波大学システム情報系教授）の計算折り紙の研究に興味を持ち、三谷氏の論文や著書を参照しながら、折り紙の数学的背景や、折り紙幾何学におけるCGの応用技術について学んでいました。 また、三谷氏は、ORI-REVOという軸対称な曲線折り紙を簡単に設計できるソフトウェアを開発されていたとのことで、科学部では本ツールを用いて実際に曲線折り紙作品の制作も行いました。 これらの折り紙理論および作品展示を、文化祭にて発表するという活動を行いました。

クリエイティブコーディングとしてのCG

大学に入学してからは3DCGソフトウェア「Blender」を用いた個人制作活動をしていました。

この頃からOSSであるBlenderの内部実装に興味を持ち始め、Blenderの主要言語であるC++を触り始めました。 その後、大学でプログラミング学習を受け始めたこともあってクリエイティブコーディングにも興味を持ち、Proccesingやp5.jsによる作品を制作し、公開していました。 この頃からWebの表現力の高さに惹かれWeb技術を学び始めました。

ネットワークセキュリティ編

大学での専攻

高校生の頃、Minecraftが好きだった私はレッドストーン回路という電子電気回路を模したMinecraft上のアイテムを用いて、半加算器/全加算器による計算機を作成していました。 この仕組みが実際のコンピュータでも用いられていることを面白く思い、立命館大学情報理工学部に進学してコンピュータサイエンスを学ぶこととなりました。 専攻はネットワークセキュリティであり、コンピュータサイエンスの基礎からネットワークの仕組み、セキュリティ分野を幅広く学びました。 上原哲太郎教授（https://x.com/tetsutalow）のサイバーセキュリティ研究室に配属し、幅広いセキュリティ課題に取り組んでいます。学習の過程で、応用情報技術者試験や情報処理安全確保支援士試験に合格し、現在は登録セキスペ第028175号となり、継続的にセキュリティ分野の体系的な理解を深めています。

ネットワークプログラミング

TCP/IPなどネットワークレイヤの理解を深めるため、マルチスレッドによるWebサーバををC言語でフルスクラッチで実装しました。詳細について「3興味ある分野に関する問い」の回答にて紹介します。

構文解析編

私は大学の講義にてオートマトンおよび言語理論を学んで興味を持ち、個人開発や研究において、正規表現や構文解析に関連した取り組みを行なってきました。

正規表現のReDoS脆弱性

ReDoS脆弱性は正規表現の評価時間が爆発的に増えてDoS攻撃につながってしまうというもので、この脆弱性の存在を知った私は、その理論的背景を調査しました。 ReDoS脆弱性の原因はVM型正規表現エンジンのバックトラックの爆発的増加であることは様々な記事で言及されています。 ただ、原因日々の開発の中で記述した正規表現がReDoS脆弱であるかを判断することは難しいだろうという所感もありました。 そこで、エディタ上でReDoS脆弱かを判定できるVSCode拡張機能を開発し、リリースしました。 2024年5月現在400インストールされており、今も継続的に機能拡張を行なっています。

また、簡易的な判断として人の目でReDoS脆弱かを判断したいときに、バックトラックが増加するかという観点だけでは難易度が高いだろうという所感もありました。 そこで、下記のブログにて、ReDoS脆弱かを「パッと見で」判断できるような経験則を理論的背景とともにまとめました。 投稿後多くの方にご覧いただき、様々なコメントをいただけて知見がより深まりました。

自作電卓

電卓自作のため、再帰下降構文解析による四則演算器ライブラリを実装しました。

別プロダクトとして、パーサコンビネーターを利用した五則演算器「見せ算演算器」、およびその電卓GUIを開発しました。 （見せ算とは、四則演算に次ぐ五則目として提案された架空の演算方法のこと）

2038年問題研究

卒業研究および修士研究では、2038年問題をテーマに、C/C++ソースコードから2038年問題の原因となりうるコードを検出し、2038年問題の脅威性を示すという研究をしています。 提案手法では、対象のソースコードを抽象構文木解析した上で、得られた型情報や字句情報をもとに2038年問題判定するという検出手法を提案しています。 実装では、Clang/LLVMを用いて抽象構文木解析および2038年問題判定するCLIツールを、C++で実装しました。研究の詳細については「2 課題への姿勢に関する問い」で紹介します。

Web

コンピュータクラブでの教育活動

前述したクリエイティブコーディングの一環でp5.jsに触れてから、その表現力の多様さに惹かれてWeb技術を学び始めました。所属する立命館コンピュータサークルではWeb班を立ち上げ、プロジェクトリーダーとしてメンバーに対し教材制作や講義、制作支援などを行いました。Web初学者のメンバーでも基礎的な開発力をつけてもらうため、Webの基本的な仕組み、Webフロントエンドの諸技術および歴史的経緯、Webフロントエンド/バックエンドのチュートリアルについて教材を作成し、複数回にわたって講義を行いました。

JPHacks

日本最大規模の学生ハッカソン「JPHacks 2022」では、スマホをリモコン化する共同プレゼンテーション支援ツール「スマートポインター」を開発し、関西ブロックにてBest Hacking Sprint Awardを受賞しました。 また、決勝大会という位置付けのAward Dayに参加し、イノベーター認定賞を受賞しました。 開発背景としては、複数人でプレゼンテーションを行う場合、スライドの切り替え担当者とスピーカーが一致しない場合があります。 しかし、スピーカーが逐一「次のスライドお願いします」と依頼するのは面倒であり、聴衆に煩わしさを与える場合もあります。 そこで、手元のスマートフォンをリモコン化し、リモートにあるホストPCのスライドを共同で操作できるプラットフォームを開発しました。

実務開発での品質改善

2022年1月から現在までの2年半、京都のスタートアップ会社にてWebエンジニアとして従事してきました。 具体的には、███████プロジェクトで内部品質改善を行いました。経緯としては、███████████████████████████████████████████████████████████████████。この課題に対し、「質とスピードはトレードオフではなく、品質の劣化はリードタイムの増加につながる」と主張し、品質改善担当として声を上げ、内部品質および開発者体験の向上のための取り組みを行いました。 ██████████████████████████████████████████████████。 ██████████████████████████████████████████。 █████████████████████████████████████████████████████████████████████████████████████。 █████████████████████████████████████████████████████████████████████████████。

ハッカソン型インターン

三井不動産株式会社の不動産DX推進サービスを開発するハッカソン型インターンでは、「大都会渋谷の宮下パークで虫取りを」というコンセプトでARサービスを提案し、メンター賞を受賞しました。 株式会社CARTA HOLDINGSの3週間のインターン「もの創り実践プログラムTreasure 2023」では、「技術書のオンライン読書会サービス」を提案・実装し、グランプリ賞とバックエンド賞を受賞しました。React/GraphQL/Go/PostgreSQL を採用し、アイデア〜フロント実装〜バックエンド実装〜発表まで担当しました。

実務型インターン

NTTコミュニケーションズ株式会社の2週間の実務型インターンでは、ビデオ会議ツールNeWorkのプロジェクトにて、TypeScriptを用いた新機能開発を行うというテーマで参加しました。リアルタイムチャット機能のプロトタイプを提案実装し、後に提案が製品に採用されたとのことでした。 Wantedly株式会社の3週間のインターンでは、DX squadにてWantedlyのコードベースにRubyの型システムを導入すべきかどうかという概念検証を行い、その結果をWantedly Techブログに投稿しました。

GMOペパボ株式会社の2週間のインターンでは、SUZURI 事業部にて、ショップページ刷新実装、SNSシェア文生成機能実装を行い、本番環境にリリースしました。また、インターンの内容をGMOペパボTechブログに投稿しました。

C/C++編

ネットワークセキュリティ編、構文解析編と紹介してきましたが、これらの技術分野に横断的に関係したのがC/C++による開発でした。ネットワークプログラミング、競技プログラミング、C/C++を対象とした2038年問題のClangによる検出研究、████████████での自律走行車の研究開発などで経験しました。

その他の活動

執筆活動

本回答でも引用していますが積極的に執筆活動を行なっており、学びの過程をアウトプットする機会を定期的に設けています。

メール誤送信研究

修士論文テーマのほかに、共著としてメール誤送信に関する研究にも携わっています。2024年3月には「セキュリティ心理学とトラスト研究会」で以下論文を発表しました。

研究室での卒論執筆支援

研究室の学部4回生に対して行った卒論執筆支援活動について紹介します。 1点目は、論文執筆用のLaTeX環境「CyTeX」を開発したことについてです。 CyTeXは、環境構築が容易でGit管理可能、無料で利用可能な日本語LaTeX執筆環境です。 GitHub Codespaces で LaTeX 環境を構築でき、ブラウザから TeX ファイルの編集が可能です。 VSCode for the Web が利用可能なブラウザさえあれば、LaTeX 環境を構築できます。 また、ローカルのDocker環境でも使用でき、かつDocker環境もamd64/arm64の両環境に対応しています。 開発背景について、論文提出の締め切りに追われている人にとって執筆環境構築は面倒な作業で、また、例えば自宅PCと研PCといった、複数の環境で構築したくなった場合も面倒でした。 卒論修論に関しては、大学から配布される卒論修論専用のTeXファイルのテンプレートがあるのですが、各々がファイルをダウンロードしてきて〜任意のTeXパッケージを入れて〜章立てして〜という作業も面倒でした。 理想的には、全員共通のテンプレートを用意し、全員が行う面倒な作業はなくしたいところです。 そこで、環境構築が簡単で、環境差異が少なく、Git管理ができて、無料で利用できて、論文テンプレートを配布できる、そんなLaTeX環境を目指してCyTeXを開発しました。

2点目は、卒論執筆指南書および卒論執筆講座についてです。 12月初旬にサイバーセキュリティ研究室のB4生を対象とした「卒論執筆講座」を開講しました。 開講した経緯としては、サイバーセキュリティ研究室では これまで、特に推奨される論文執筆環境というものはなく、各学生が自由に環境を選んで執筆していました。 使いたい環境がある人にとっては問題ありませんが、はじめて論文を執筆するB4生にとって、そもそもどんな手順で、何に気を付けて卒論を書いていけば良いかわからないという悩みにも繋がっていました。 そんな課題感から、よりスムーズに卒論を執筆し始められるように卒論執筆指南書を作成し、共有することにしました。 講座では、LaTeX環境の選び方、Gitによるバージョン管理および基本的な使い方、論文執筆の心得、論文執筆のTipsについて共有しました。

3点目は、卒論執筆におけるGitHubの運用についてです。 前述した卒論執筆講座では、論文バックアップ環境としてGitHubを紹介し、環境構築までのチュートリアルも行いました。 また、昨年度からは論文レビューにGitHubのPull Request機能を用いるよう提案し、実際にその恩恵を受けることができました。 論文添削でGitHubを用いた恩恵として、Suggestion機能によるレビューコメント内で修正案の提案できること、他のレビュアーのコメントを閲覧できること、解決済みマークで修正済みかを判別できること、などがありました。

セキュリティシンポジウムへの参加

最近ではセキュリティシンポジウムにも積極的に参加しています。2023年6月にサイバーセキュリティシンポジウム道後では、研究発表を行い学生研究賞を受賞しました。 2024年3月には九州サイバーセキュリティシンポジウムに参加し、民間のセキュリティエンジニアだけでなく、官公庁や警察関係者、他大学の先生方など大学外の方々との交流を深められました。

今後

私は今後、セキュリティ分野に深く精通したソフトウェアエンジニアになりたいと考えています。 インターンシップでのWebサービス開発を通じて、ソフトウェアエンジニアがセキュリティ知識を持つことの重要性を強く感じました。 近年のデリバリー速度が求められる開発スタイルの中では、セキュリティベンダーによる第三者監査を行うばかりではなく、開発者自身がセキュリティ意識をもつことが大切だと考えています。 例えば、デプロイ頻度の高いサービスにおいて毎回ベンダーチェックすることは現実的ではないがセキュリティホールがあるままリリースすることは許容できなかったり、他にも、頻繁に変わるサービス仕様のすべてをセキュリティベンダーに伝えることが難しかったり、などの問題点があります。 そのため、開発組織内での、DevSecOpsの仕組みの構築、脆弱性を生みにくいソフトウェア設計、バグハンティングの知見をもつことが好ましいと考えています。 私はそういったセキュリティスキルをもったソフトウェアエンジニアを目指し、セキュリティネクストキャンプでは、少しでも多くのセキュリティ技術を習得したいと考えています。 また、セキュリティキャンプに参加される多くの関係者の方と知見を共有し、セキュリティ業界の未来に共に貢献できる仲間を見つけること期待しています。

2 課題への姿勢に関する問い

自身で何らかの技術的な疑問を設定し，その疑問を解決しようと取り組み，その過程を示すことで，自身の技術力や課題に取り組むやりかたを説明してください． (疑問の例：実行ファイルはどのような構造になっているのだろう？ pingコマンドを実行すると何が起きるんだろう？ オンラインゲームはどうやって通信対戦を実現しているのだろう？ といったようなことです) 設定する疑問は何でも構いませんし，解決しなくても構いません． 解決できたかどうかではなく，いかに課題に取り組むかという点を評価します．

きっかけ

前述の通り、大学生活の中でC/C++による開発を多く経験してきました。 この中で、特にC言語の型に起因するバグや脆弱性の生まれやすさを実感していたこと、技術的負債に興味があったことから、2038年問題をテーマに卒業研究、修士研究を行ってきました。 本回答では、研究概要、貢献、課題解決のアプローチ、実装のアプローチについて紹介しながら課題への姿勢を示します。

研究概要

修士研究では、「2038年問題の原因となりうるソースコードの自動検出手法の提案と実装」をテーマに研究を行っています。 2038年問題は、UNIX timeという時刻表現形式に起因する問題です。 UNIX timeは歴史的経緯により32bit符号付き整数型で表現されることがあり、その場合、2038年1月19日3時14分7秒降の時刻で整数オーバーフローが引き起こります。 この整数オーバーフローによってシステムにさまざまな不具合が発生する可能性があり、これを2038 年問題と呼びます。 2038年問題は、影響範囲の広さや修正の困難さから深刻であると主張されています。 2038年問題への対応として、64bitなどの32bitを超えるデータサイズでタイムスタンプ値を扱う対策が一般に知られています。 この対策において、タイムスタンプ値のデータサイズはデータフローの中で一貫して32bitを超えるよう維持される必要があるが、どこか一箇所でも32bit符号付き整数型にダウンキャストされると、整数オーバーフローを引き起こす可能性があります。 また、このダウンキャストを既存手法で発見することは困難であり、検出手法の確立が求められます。 そこで本研究では、2038年問題の原因となりうるコードの検出手法を確立することを目指しています。

貢献

これまでの修士研究において、C言語ソースコードから2038年問題の可能性のあるコードを抽象構文木解析により検出するツールを開発しました。 さらに、開発したツールを用いて普及率の高いオープンソースソフトウェアを対象にした調査を行いました。 その結果、約1/3のプロジェクトにおいて潜在的に2038年問題のあるコードが発見され、2038年問題の脅威性が示されました。 また、この過程において、論文執筆/研究発表を実施しました。

今後の予定について、現状 本研究の検出ツールではFalse Positiveな検出が存在するため、解析精度が向上するよう検出ツールの改良を行う予定です。 その上で、2038年問題の脅威性評価のための大規模な調査を行い、さらに学会にて成果発表を行う予定です。 最後に、修士論文にて、改良した2038年問題の検出手法、および脅威性評価のための調査結果をまとめる予定です。

課題解決のアプローチ

「①観察による仮説形成→②仮説を具体論として導出→③仮説の検証」というプロセスで問題設定/問題解決を試みています。 ①観察による仮説形成について、まず、2038年問題のにおける課題の一つに、影響するレイヤが非常に広いため脅威の大きさを分析することが困難であるということが挙げられます。 そこで、2038年問題を抱えることが既に判明しているソフトウェアを調査、分類しました。 この調査の過程で得られた知見をもとに、「C言語の time_t 型の64bit化で防げない2038年問題」に着目し、この問題領域での脅威は大きいだろうという仮説を立てました。 ②具体論の導出として、このような2038年問題には具体的にどのようなパターンが存在するかを求めました。 これには、JISX3010:2003などのC言語の言語仕様や、MISRA-CやCERT-CなどのC言語セキュアコーディングルールを参照しながら求めました。 ③仮説の検証として、次にこの問題領域のリスクを分析するために、ソースコード解析を用いた検出手法を考案し、さらにOSSを対象とした評価実験を行いました。 結果としては、脅威が大きいと評価できる結果が得られ、これと事前調査の結果とを合わせることで仮説を検証できました。 最後に学会論文として体系的にまとめました。

実装のアプローチ

抽象構文木（以下、AST）解析を行い、検知対象コードを見つけることが提案手法でした。 この手法を検知ツールとして実装する過程を振り返って紹介します。 検知ツールの要件としてはC/C++に対してAST解析ができることがありました。 これに加えて、独自ルールを定義するプラグインが作れること、コミュニティが大きく研究分野でも採用例が多いことから、LLVM/ClangのClang Static Analyzerを採用しました。 ClangによるAST解析の方法にはいくつかありますが、卒業研究の時には、最もeasyに扱えるAST Matcherの仕組みを使って検出ツールを実装していました。 AST Matcherは、Clang ASTに対してパターンマッチで対象のASTノードを取得できる仕組みです。 clang-queryというCLIツール用いて、AST Matcherを投げることで、検知対象のコードを発見するということを卒論時にはしていました。 しかし、検出手法の要件上、再帰的な処理が必要となり、これがAST Matcherの表現力では難しいということがわかり、別の手段が必要になりました。 そこで、AST Matcherで対象のノードを取得した後に、得られたClang ASTノードから、子ノードを提案手法の条件にしたがって再帰的に探索することはできないかと考えました。 clang-queryやClangコンパイル時の静的解析では、Clang ASTノードを直接参照しているはずなので、そのような仕組みはあるはずです。 もっというと、Clang ASTを参照する仕組みがライブラリがClangから提供されていれば嬉しいなと思いながらドキュメントや書籍を読み探しました。 すると、ClangLibというライブラリとして提供されているとわかり、これを用いて実装することとなりました。 実装は、公式ドキュメントや書籍、他のGitHubリポジトリでの実装を参考に行いました。 ただ、難しかった点として、LLVMはメジャーバージョンによってライブラのインターフェースやディレクトリ構造がかなりことなるため、サンプルコードそのままというわけにはいかず、使用バージョンのClangソースコードを参照しながら実装する必要はありました。

3 興味ある分野に関する問い

セキュリティ・キャンプ ネクストの講義の一覧を見て，その中から興味のある講義を選び，その講義で扱うテーマに対して自分が考えること，興味，疑問，課題，自分なりの考察などを説明してください． その分野について知識があるかどうかではなく，いかに興味や疑問を持ち，課題を考え，自分なりに調べて考察するかといった点を評価します．

セキュリティネクストキャンプでの講義の中でも、特に興味を持っている講義について述べます。

K2『法律と倫理』

所属する立命館大学の上原哲太郎研究室では、不正アクセス禁止法、デジタルフォレンジック、プライバシーや個人情報保護法、遺産相続、電子文書といった「法律と倫理」に密接に関わる分野をテーマにした卒業研究、修士研究があり、日々のゼミでも個人の研究テーマを超えて議論をしています。また、上原研究室では、産官学連携の一環で大阪府警や京都府警、滋賀県警と協力した取り組みを行っていたり、デジタルフォレンジック研究会のデジタル・フォレンジック・コミュニティの運営を行っていたりと、大学外の様々な機関と協力しながらサイバー犯罪対策への取り組みを行っています。私個人としても、サイバーセキュリティシンポジウム道後や九州サイバーセキュリティシンポジウムに参加した際には、警察組織や民間企業の方からサイバー犯罪対策の現状を学び、特にセキュリティという学問では大学を超えたコミュニティ形成の中で法律と共にサイバー犯罪対策していくことが大切であると強く感じました。講義では、サイバーセキュリティに関する法律への理解を深めた上で、民間企業、大学、警察、個人など様々な視点に立ちながら法律、倫理、道徳上の問題点について議論したいと考えています。

N2『C++ ライブラリ開発』

「実務開発での品質改善（問1にて先述）」の経験、およびC++による開発経験から本講義に興味を持っています。前者の経験では、ジョインしているプロジェクトでテスト容易性や理解容易性、変更容易性の高い設計手法の学習および実践を行いました。後者の経験としては、問2で先述したC++およびClangライブラリを用いたツール開発や、競技プログラミングで、C++を使用しています。また、問2の回答にて、修士研究でC言語の言語仕様を参照しながら提案手法の検出対象を定義したと先述しました。Cの言語仕様はコンパイラ依存や未定義動作が非常に多い（例えばint型、long型といった基本的な型ですら実装依存）ところがCのやっかいな仕様であると考えています。C++の言語仕様ではこのあたりの環境差異やバージョンによる差異がどの程度多いのか、また、ライブラリ開発という汎用性が求められる実装においては何に注意すべきかなどについて、本講義を通して学べればと考えています。

N4『Content Delivery Network を自作してみよう』

CDNへのモチベーション

私は3年前からアルバイトでWeb開発プロジェクトに従事しており、特にWebフロントエンド技術のパフォーマンス改善に興味を持っています。パフォーマンス改善には、ブラウザでの処理の高速化やキャッシュの利用などがありますが、最近では、ページ速度がGoogle SearchのSEOに関与するようになった（https://web.dev/articles/vitals）、ことから、キャッシュの利用が重要性を増していると考えています。究極的には、CDN Edgeからあらゆるレスポンスを返すアーキテクチャ、リソース取得に関してアプリケーションサーバに到達させないアーキテクチャが理想的だと考えています。そんな中、Cloudflareの施策はゲームチェンジャー的な要素があると感じており、特に、Cloudflare Workers、R2、D1、KVに注目しています。従来のCDNは静的ファイル配信の最適化が主な役割でしたが、これらの技術を活用することで、リソース取得をすべてCDN Edgeから返す構成が可能だと考えています。具体的には、CQRS（コマンドクエリ責務分離）ライクなアーキテクチャを構築できると考えています。つまり、Command（Write）はアプリケーションサーバに問い合わせ、Query（Read）はCloudflare Workersからすべて返すという構成です。具体的には、WorkersがCloudflare R2（オブジェクトストレージ）、D1（SQLデータベース）、KV（Key-Value Store）に問い合わせ、あらかじめリソースを取得しておくという構成です。 以上のように、CloudflareのようなCDN技術とその進化に期待しており、また、CDN内部の仕組みについても学びたいと考えています。

CDN自作にむけての学習

CDN自作に向けて、まず「Web配信の技術（田中祥平 著）」を読み、HTTPキャッシュ、プロキシサーバ、およびCDNサーバでのキャッシュの仕組みについて学びました。その上で、簡単なCDNを構築するため、下記リンクの画像のようなアーキテクチャ設計を行いました。

自作CDN構成図
（2024/8/20追記：GSLBの位置が色々間違ってるので注意ですmm）

まず、キャッシュサーバおよびL7ロードバランサの実装を試みました。今回はCloudflareが開発しているリバースプロキシフレームワーク「pingora」を用いて実装を行いました。pingoraのGitHubリポジトリに置かれている一部モジュールのドキュメント、DOCS.RSを参照しながら仕様を把握しました。L7ロードバランサの実装は、LoadBalancer構造体を用いて行い、upstreamの選択アルゴリズムとしてラウンドロビン、IPハッシュ、ランダムをサポートしていることがわかりました。キャッシュは、pingora::cacheモジュールを使用して実装しました。今後の展望として、L4ロードバランサやGSLBを実装したいと考えており、講義ではこれらの知見を深めたいです。また、セキュリティに関する話題では、CDNの設定ミスに起因する事故が発生することがあります。例えば、CDNがプライベートキャッシュを他ユーザに配信してしまうといった問題です。CDNの内部実装においてプライベートなキャッシュを適切に実装する方法についても気になっています。さらに、CDNやプロキシのキャッシュキー戦略についても学びたいと考えています。例えば、セキュリティ要件上、どのリソースをキャッシュすべきか、そのキャッシュキーは何か、オリジンに流すヘッダを変更するかしないか、クライアントに流すヘッダを変更するかしないか、といった観点があると思います。そのあたりについても講義で詳しく聞いてみたいです。

N6『TCP/IPプロトコルスタック自作入門』

大学3回生の頃、TCP/IPなどネットワークレイヤの理解を深めるため、C言語でWebサーバを実装しました。具体的には、sys/socket.hを用いたソケット通信を行い、HTTP/1.1のリクエストを解析してリソースを返すプログラムです。この実装では、ネットワークインターフェース層、インターネット層、トランスポート層がライブラリに隠蔽されており、アプリケーション層が主の実装でした。

この経験から、隠蔽されていたレイヤの実装にも挑戦してみたいと感じるようになりました。特に、ネットワークデバイスの扱い方、IPデータグラムの入力と検証、IPルーティング、ソケットAPIの実装について、自作してみたいと考えています。そこで、KLab Expert Camp「TCP/IPプロトコルスタック自作開発」の資料およびmicropsの実装を拝見し、学びを深めました。その過程で、いくつかの疑問が生じました。まず、TCPは信頼性の高い通信を保証するために再送機構やフロー制御、輻輳制御など多くの機能を備えていますが、通信途中でパケットが乱れた場合にどのようにしてTCPコネクションを再同期し、正常な状態に戻すのかについて具体的な実装レベルでの詳細を理解したいです。また、ARPキャッシュポイズニング攻撃の防止策として、どのような実装上の工夫が可能かについても、本講義を通して詳しく知りたいと考えています。

4 その他に関する問い

その他，アピールしたい点などあれば自由記述で回答してください．

モラルや法律遵守の意識と、高度な情報セキュリティ技術をもった技術者になりたいと強く思っています。 Seccampの5日間を通じて、ネットワーク技術やセキュリティに関する深い知識を身につけ、実践的なスキルを磨くことを楽しみにしています。 この機会を最大限に活かし、責任ある技術者として成長したいと考えています。

2023年振り返り & 2024年の抱負

雑に2023年の振り返りと2024年やりたいことを書き出してみる

2023年振り返り

1月

2月

  • 卒論発表会
  • 卒業旅行
  • 追いコン
  • 卒業祝い飲み会
  • Web開発アルバイト

3月

  • スノボ in 奥伊吹
  • 金沢旅行
  • 卒業式
  • YAPC
  • 名古屋旅行

4月

  • 大学院入学
  • 夏インターンの面接/面談
  • IoTセキュリティセンターでのポスター発表
  • DICOMOシンポジウムに向けて研究進捗
  • セキュスペ受験（合格💮）

5月

  • 夏インターンの面接/面談
  • 高校の同窓会
  • 研究計画書の提出
  • DICOMOシンポジウムへの論文投稿
  • Kyoto.js 勉強会への参加

6月

  • 夏インターンの面接/面談
  • サイバーセキュリティシンポジウム道後での研究発表、道後観光
  • TOEIC
  • 研究室公開

7月

8〜9月

10月

11月

  • 某報処理学会論文誌 投稿に向けて研究進捗

12月

  • 某報処理学会論文誌 投稿

2023年 KPT

Keep

  • Notionに覚書きするようになり、記憶のトレーサビリティが上がった。TODOもメモも研究も就活も
  • 研究のおもしろさがわかってきた。進捗を出しながら成果を発表する機会を設けられた（対外発表 × 3、論文投稿 × 2、研究賞受賞 × 2）
  • インターンでは色々な人と出会えて刺激になったと同時に、現状の実力や課題感への解像度が高まった。
  • 旧友と会う機会を定期的に設けられた。他分野の話を聞くことで、今まで見えていなかった自分野の特長を発見できた。
  • Web開発アルバイトを2年続けられて、継続的にWeb技術を触る機会を設けられた。

Problem

  • やりたいことが多すぎて手がつけられてない
  • 学びが多い一年でブログネタはたくさんできたが、優先度の高いタスクに押しつぶされ公開まで至っていない
  • 本選考受けなさすぎ。就活まずい
  • 教養を深める時間を取れなかった
  • ギリギリの計画になりがち

Try

  • 就活しよう（就活しよう）
  • 作業時間、作業効率を上げるためにも心身ともに健康を維持したい
  • 優先度コントロール、スコープコントロールに力を入れたい。特にアウトプットの優先度を上げよう。

2024年やりたいこと

  • 研究で海外の査読付き学会に参加したい
  • 英語力をつけたい
  • 就活を自分が満足できる形で終えたい
  • データベーススペシャリスト取りたい
  • バグバウンティやりたい
  • 学びをブログ等で発信していたい
  • Scala/Rust 完全に理解したい
  • 健康第一