パスキーって何だろう?

はじめに

24年入社の吉岡です。
いつ頃からでしょうか、Googleにログインする際に「パスキーを使用しますか?」と聞かれことが多くなった気がします。以前から気になっていたのでパスキーに調べてみることにしました。「分かっているようでまるで分かってない…」と思う無数の単語や用語に直面することとなり、改めて日々精進しなければと感じました。

パスキー(Passkey)とは
FIDO認証(FIDO2.0)というパスワードを使用しない認証で使用される認証器、本人確認を行うためのデバイスやソフトウェアです。
公開鍵暗号方式を用いており秘密鍵は端末側にのみ保存され公開鍵はサーバ側に保存されるので、ネットワーク上でパスワードを送受信する必要がありません。
さらに、端末のPINコード(ロック画面のパスワード)や生体認証(指紋認証や顔認証など)と組み合わせて鍵の生成と署名(秘密鍵を用いた暗号化)を行うので、多要素認証も兼ねています。

パスキーを用いたログインの流れ
1 ユーザがサーバに対してログインしようとする
2 サーバからユーザにチャレンジ(一度しか使用しない乱数)を生成し送信する
3 ユーザが端末内でPINや生体情報を用いて本人認証を行う
4 本人認証に成功するとチャレンジに秘密鍵を用いて暗号化 (署名)しサーバに送信する
5 サーバは公開鍵を用いて送信されてきた署名済みチャレンジを復号する
6 復号に成功するとサーバはユーザのログインを認証する

パスキーを使用するメリット
安全性
秘密鍵はユーザの端末以外に送信されることがないので、パスワードを盗まれたり推測されたりするリスクを抑えることができる。

利便性
パスワードを使用しないので複雑なパスワードを覚えておく必要がなくパスワードマネージャーも不要である。
パスキーをユーザの別端末と同期(クラウド同期)できるものであれば、1つの端末で登録すると複数端末からもログイン可能になる。

デメリット
対応サービスが限定的
パスキーに対応しているウェブサイトやアプリケーションは急速に増えつつあるが対応していないものも多くある。

バックアップ手段が必要
端末に紐づくためパスキーの場合を紛失した際や傷病による身体的な変化や認証用端末の故障で生体認証が困難になって際へのバックアップ手段が必要。

脅威がなくなるわけではない
より安全性の低い古いプロトコルや認証方式を強制するダウングレード攻撃が報告されており、パスキーを使用している=安全ではない。

実際に使ってみた
・スマートフォンからパスキーを用いてログイン(* 個人用に作成したアカウントです)
1 非ログイン状態でGoogleのログイン画面を開く

2 アカウント名を入力し、パスキーでのログインを選択する


3 パスキーを作成する

4 作成したパスキーを用いてログイン


5 ログイン成功

・PCでスマートフォンのパスキーを用いてログイン
1 PC:スマートフォンをBluetoothで同期する
2 PC:非ログイン状態でGoogleのログイン画面を開く


3 PC:パスキーと紐づいたアカウント名を入力し、パスキーでのログインを選択する


4 スマホ:GoogleレンズでPCに表示されたQRコードを読み込む(画像略)
5 スマホ:作成したパスキーを用いてログイン(画像略)
6 PC:ログイン成功

あとがき
パスキーを用いた認証はパスワード認証よりも安全だとは分かったのですが、端末が壊れたり変更したり場合を想定すると正直不安は残りますね…。
将来的には、業務でパスキー認証を使用したり組み込んだりするかもしれないので、引き続き注目していこうと思います。

tips:関連用語備忘録
パスキーについて調べる中で出てきた単語や用語を理解できていないと感じることが多くあったので、その一部を記載させていただきます。

認証とは
適切なアクセス権を持つ適切な人物やサービスがリソースに到達できるプロセス

・認証の三ステップ
1 識別 ユーザが誰であるかを確認(例 ユーザ名・アカウント名を入力)
2 認証 示した通りのユーザであるかを確認 (例 パスワード入力を入力)
3 認可 ユーザがアクセス権限を持っているかの確認 (例 システムがユーザ権限を確認)

・認証の三要素
知識情報
ユーザ本人だけが知っている情報
例 パスワード、認証番号、秘密の質問など

所持情報
ユーザ本人が所持しているもの
例 身分証明書、クレジットカード。スマートフォン、鍵、印鑑など

生体情報
ユーザ本人の身体に固有な情報
例 指紋、声紋、虹彩、顔、静脈など

・認証器
本人確認を行うためのデバイスやソフトウェアであり、鍵の生成と署名(秘密鍵を用いた暗号化)を行う。

FIDO認証
FIDO(Fast IDentity Online)はファイドと読み、ラテン語で信頼を意味する「Fido」が由来とされています。
FIDO1.0は専用のハードウェアが必要で、FIDOクライアントと認証器が分かれている
FIDO2.0はデバイス自体が認証器(プラットフォーム認証器)として使用できる。

・Web Authn(Web Authentication)
FIDO2.0の基幹を成しているブラウザと認証サーバ間の規格
Webブラウザに組み込むことでFIDO認証を行えるようにする標準API(Java Scriptで記述されている)

・CTAP2 (Client to Authenticator Protocol 2)
FIDO2.0の基幹を成している認証器とブラウザ間の規格
FIDO2.0に対応した端末と外部の認証器の通信の橋渡しを担い、多様な認証デバイスを利用できるようにする。
多様な認証デバイスの例 PINコード認証・生体認証・パターン認証

参考:

Googleが激推しする認証方式「パスキー」って何だ?パスワード …
厚生労働省:次世代認証技術「FIDO」
Passkey(パスキー)とは | 用語集 – CloudGate UNO

FIDO認証の落とし穴:ダウングレード攻撃による新たな脅威

2025年 新入社員ブログ 篠原05 [好きなラジオを作れるAI]

2025年4月入社の篠原です。

6回に分けて、今までの業務で学んだことや自分のことについて紹介します。今回はその5回目になります。見ていただけると嬉しいです。

今回は好きなラジオを作れるAI、「NotebookLM」についてご紹介します!

タイトルにはわかりやすくラジオと書いていますが、正確に言うとラジオではなくポッドキャストです。
違いとしてはラジオというのは、リアルタイムで電波を通して聞くものを指し、ポッドキャストはインターネット経由で好きな時に好きなだけ聞くものを指します。

NotebookLMとは

NotebookLMとはGoogleが提供するAIアシスタントの一つで、資料を自動で要約してくれて、それを音声化してくれるものです!
つまり、AIがポッドキャストを作ってくれます!
資料は、Googleドキュメント、PDF、ウェブページURL、YouTube動画リンクなどを自分で選んでそれを送ることができます。

また、どのくらいの長さで音声化するかも決めることができます。標準に設定しておくと、大体15分程度のポッドキャストを聞くことができます。

女性と男性が実際のポッドキャストかのように会話しているものが生成され、何か作業しているときや、電車での移動中に聞くことできるのでおすすめです!

他の生成AIとの違い

従来の生成AIはインターネット上の膨大な情報をもとに回答を生成しているのに対し、NotebookLMはユーザーがアップロードした資料だけを参考にして回答を生成するので、どのくらいの範囲で要約してほしいかを自分で決められるのが特徴です。

これにより正確な情報に基づいた回答を生成するため、関係ない知識による誤回答を減らすことができます。

イメージとしては、

ChatGPT/Gemini
アイデアを出したいときや、AIが持つ幅広い知識を利用し、対話することに向いている

NotebookLM
資料について詳しく知りたい、要点を整理したい、それについての会話をラジオ感覚で聞ける

どちらのAIにも良さがあるのでうまく使い分けできるといいですね!

実際に生成してみた

使い方も説明しながら実際に生成してみます!

ブラウザでも操作できますが、今回は実際に使用する可能性の高いスマホのアプリで説明します!一度でいいのでぜひ試してみてください!

1.ログインする
まずはNotebookLMのアプリをダウンロードし、Googleアカウントでログインします。

2.ソースのアップロード
次に新規作成のボタンがあるので押してもらうと、ソースのアップロード画面に移ります。

ここでファイルをアップロードすることもできますが、今回は実際に検索してみようと思います。
上のウェブからソースを見つけるという欄で好きなテーマを調べます。今回は「おすすめのラーメン店」で検索してみます。

10件表示されるので、ここで自分がいいと思ったものだけチェックを入れることができます。今回はすべて選択してインポートを押して次に進みます。

3.音声生成
下にソース、チャット、スタジオという項目があり、スタジオというところで音声解説を生成することができます。
(ソースでは先ほどインポートしたソースを確認でき、チャットではチャット形式で質問ができたり、指示を出せます。)


スタジオを押すと、下にデフォルトで生成されたものがありますが、これは英語の音声になっています。上の音声解説を押してもらうと、日本語の音声を生成できます。

音声解説の横にあるペンのマークを押すと、長さや言語を変えることもできます。

実際に生成されたものを聞いてみると、ラーメンが今すぐ食べたくなりました。本当に人間が話しているみたいで、もはや怖いです…

少し長くなってしまいましたが、面白いのでぜひ試してみてほしいです!

今回のお話はここまでで、次回は入社から8か月経って思ったことについて話していきます!
最後までご覧いただきありがとうございました!

『アイデアのつくり方』読書メモ     技術職にとっての創造の技術

こんにちは、中島です。
今回は、ジェームス・W・ヤングの名著『アイデアのつくり方』を読んだ感想と内容をまとめました。

この本はたった60ページほどと短く、一見すると軽く読めそうですが、実際には「良いアイデアはどのように生まれるか?」という根本的な問いに、非常に本質的なアプローチで答えてくれています。

この本を読んで「技術職にも通じる考え方だ」と強く感じました。
以下では、その内容と5つのステップ、そして読んで感じたことを詳しくご紹介します。

◆ アイデアとは「既存の要素の新しい組み合わせ」

著者ヤングは、アイデアとはまったくのゼロから生まれるものではなく、「既存の要素」を新しい視点で組み合わせたものだと述べています。

この考え方は、システム開発や設計、コードの改善など、日々何かしらの課題に向き合っているエンジニアにとっても非常に腑に落ちます。
私たちも、技術的な制約やユーザー要件といった“素材”をもとに、最適な組み合わせを探ることが日常的です。

◆ アイデアを生み出す5つのステップ

ヤングは、再現可能な形でアイデアを生み出す手法として、以下の5つのステップを提案しています。
ここではそれぞれのステップを、本の内容に加えて技術職としての視点から解釈しながら紹介します。

1. 【情報収集】あらゆる素材を集める

まずは、課題に関する情報を集めます。ヤングは、一般的な知識と専門的な知識の両方を意識的に集めるべきだとしています。

実務の中で言えば:

  • 過去のプロジェクト事例やベストプラクティスの調査
  • 使用中ライブラリの仕様確認、業務フローの把握、類似プロダクトの機能調査など

情報を幅広く集めておくことは、後の発想に大きく影響します。何か新しい提案を求められたとき、手持ちの知識の広さと深さで対応力が決まってくると実感しています。

2. 【情報の咀嚼】集めた素材を頭の中で整理し、関連づける

次に、集めた情報を「どう組み合わせると面白くなるか?」という視点で検討していきます。

実務との接点:

  • フレームワークの制約をどう機能設計に反映させるかを考える
  • 顧客のニーズと技術的制約をどう両立させるかを検討する
  • 既存の設計と、新しい要件の接続点を探る

この段階では、すぐに答えが出なくても、頭の中でいろんなパターンを試していくような作業になります。メモや図解などを活用しながら、思考を整理することが大切だと感じました。

3. 【孵化】一旦考えるのをやめて、無意識に任せる

情報を咀嚼したあとは、あえてその課題から距離を置きます。
意識的には考えるのをやめ、しばらく別のことをすることで、無意識が働く時間をつくります。

実感としては:

  • 帰り道やお風呂に入ってるときに、突然ひらめいた
  • 他の作業中に、さっきまで悩んでいた課題の糸口が見えてきた

「考え続けるよりも、意識から手放すことで思いつく」という経験は、誰しもあるのではないでしょうか。この“孵化の時間”を怖がらずに取ることも、発想力を鍛えるためには重要だと思いました。

4. 【ひらめき】ふとした瞬間にアイデアが生まれる

十分に準備と孵化の時間を経たあと、ある瞬間に「これだ!」というひらめきが訪れます。

例えば:

  • 設計で悩んでいた構成が、一つのクラス設計案を思いついたことで一気に整理された
  • APIの設計方針が、過去のドキュメントと照らしたときに「こう組み合わせればいい」と気づいた

この「点と点がつながる瞬間」は、何度経験しても気持ちが良いものです。

5. 【検証と具体化】現実に落とし込み、改善していく

最後に、ひらめいたアイデアを実行し、現実的に機能するかを検証します。ここで初めて、アイデアが「使えるもの」になるわけです。

例えば:

  • コードとして動かし、挙動を確認する
  • チームレビューを通して意見をもらい、改善点を見つける
  • プロトタイプで動かして、ユーザーの反応を見る

「良いアイデアかどうか」は、現実に実装・運用できるかどうかで初めてわかる。だからこそ、この最終ステップが非常に重要です。

◆ 読んで感じたこと

この本を通して、「アイデアの創出もスキルであり、再現性のあるプロセスで身につけられる」ということが、何よりの学びでした。

エンジニアという仕事は、与えられた仕様を実装するだけではなく、設計や提案の場面で「今あるものをどう活かすか」「よりよくするには何を変えるか」といった視点が求められます。

また、定期的にコードレビューやリファクタリングを行う中で、アイデアを出す機会も意外と多い。
そうしたときに、「情報を集め→咀嚼し→一度忘れ→ひらめき→検証」という流れを意識することで、感覚的だった“発想”が技術として扱えるようになると思います。

◆ まとめ

アイデアとは、既存の要素の新しい組み合わせで、それを生み出すには「5つの段階」があるのものだと思いました。

『アイデアのつくり方』は、クリエイティブな職業の人向けの本と思われがちですが、実は論理性と創造性の両方が求められる技術職にも非常に役立つ内容でした。

特に印象に残ったのは、「アイデアは天才のひらめきではなく、再現可能なプロセスで生み出せるものだ」という考え方です。

つまり、”アイデアを生み出す”という行為は、特別な才能がないとできないことではなく、正しいステップを踏めば誰でも実践できるものなのです。

「なんとなく」で考えていた発想も、5つのステップに沿って見直していくことで、もっと確実に、そして効率的に進められる。
そう思わせてくれる、技術職の人にもぜひ読んでほしい1冊です。

今回はここまで
最後までご覧いただきありがとうございました!

Linux学習についてのまとめ 04        リポジトリとパッケージ

こんにちは。22年度入社の中島です。

前回はLinuC101試験に向けての学習の一環として、ファイルシステムについての記事を作成しました。今回はリポジトリとパッケージについての内容をまとめました。この記事を通じて、リポジトリとパッケージの基本的な内容、設定に使用される一部コマンドをまとめましたので共有します。

リポジトリとは?

リポジトリは、ソフトウェアパッケージを保管し、管理する場所です。リポジトリを利用すると、ソフトウェアを簡単に検索・インストールできます。多くのLinuxディストリビューションでは、公式リポジトリが提供されており、信頼性の高いソフトウェアを利用できます。

リポジトリの種類

  • 公式リポジトリ: ディストリビューション提供元が管理する信頼性の高いリポジトリ (例: Ubuntuのmain, universe)。
  • サードパーティリポジトリ: 外部の開発者や組織が提供するリポジトリ(例: EPEL, PPA)。公式リポジトリにはないソフトウェアが含まれることがあります。
  • ローカルリポジトリ: ネットワークを使わず、ローカルで管理されるリポジトリ。

パッケージ管理システム

Linuxでは、ディストリビューションごとに異なるパッケージ管理システムが使われます。以下は主要なパッケージ管理システムです。

ディストリビューションパッケージ管理システム
Debian系 (Ubuntu等)APT (dpkg)
Red Hat系 (RHEL, CentOS等)YUM / DNF(rpm)
Arch系Pacman

パッケージのインストール・削除

APTを使ったパッケージ管理(Debian系)

パッケージのインストール

これにより、システムにvimがインストールされ、vimコマンドでエディタを開けるようになります。

パッケージの一覧表示

このコマンドを使用すると、現在インストールされているすべてのパッケージを確認できます。

パッケージの削除

removeはソフトウェア本体のみを削除し、purgeは関連する設定ファイルも含めて削除します。

YUM/ DNF(rpm)を使ったパッケージ管理(Red Hat系)

yumとdnfの違いについて

yum(Yellowdog Updater, Modified)は、Red Hat系のディストリビューション(RHEL, CentOS, Fedoraなど)で長年使用されてきたパッケージ管理ツールです。
dnf(Dandified YUM)は、yumの後継として開発され、yumよりも高速でメモリ使用量が少なく、依存関係の処理が改善されたパッケージ管理ツールです。

 yum の基本的なコマンドは dnf でも使えますが、一部オプションが異なります。また、新しい環境では dnfを使うのが推奨されます。

パッケージのインストール

yumまたはdnfを使用すると、依存関係も解決して自動的に関連パッケージをインストールしてくれます。

パッケージの一覧表示

このコマンドを使用すると、現在インストールされているパッケージのリストを取得できます。

パッケージの削除

このコマンドを実行すると、指定したパッケージが削除されます。YUM/DNFは依存関係の整理も行うため、注意が必要です。

パッケージの検索

APTを使った検索(Debian系)

パッケージ名を検索

searchを使うことで、vimという名前を含むすべてのパッケージを検索できます。

パッケージ内のファイル検索

このコマンドを使うと、/usr/bin/vimを提供しているかを調べることができます。

インストール済みのパッケージを確認

このコマンドは、インストール済みのパッケージ一覧を表示し、 grepで特定のパッケージを検索できます。

YUM/DNFを使った検索(Red Hat系)

特定のファイルを含むパッケージを検索

searchを使用すると、指定したキーワードに関連するすべてのパッケージを一覧表示できます。

パッケージ内のファイル検索

providesを使用すると、特定のファイルがどのパッケージに含まれているかを調べることができます。

インストール済みのパッケージを確認

このコマンドを使用すると、システムにインストール済みのパッケージを確認できます。

リポジトリの追加と管理

リポジトリを追加することで、公式リポジトリにはないソフトウェアをインストールできるようになります。

APTでリポジトリを追加する(PPAの例)
YUM / DNFでリポジトリを追加する(EPELの例)

EPELはRed Hat系の拡張リポジトリで、多くの追加パッケージが含まれています。

おわりに

今回の記事では、リポジトリとパッケージ管理の基本についてまとめました。Linuxのパッケージ管理はシステムの運用に欠かせない重要な知識です。リポジトリの理解と適切なパッケージ管理を行うことで、安全で効率的な環境を構築できます。

LinuC 101試験に向けて、基本的なコマンドをしっかりと身につけ、試験に備えたいと思います。

今回はここまで
最後までご覧いただきありがとうございました!

Linux学習についてのまとめ 03 ファイルシステム

こんにちは。22年度入社の中島です。

前回はLinuC101試験に向けての学習の一環として、GNU/Linuxついての記事を作成しました。今回はLinuC101試験のファイルシステムについての内容をまとめました。この記事を通じて、ファイルシステムの基本的な内容、ファイルシステムのマウントとアンマウント、ファイルシステムのバックアップについて共有します。

1. ファイルシステムとは

ファイルシステムとは、コンピュータのストレージデバイス(HDD、SSDなど)上でデータを管理するための方法であり、データの保存、取得、整理を行います。ファイルシステムは、ファイルを格納する場所(ファイルシステムのブロック)とその情報を格納するメタデータを管理します。例えば、ファイルの名前、サイズ、作成日などです。

2. ファイルシステムの作成と管理

ファイルシステムを新しく作成するには、mkfsコマンドが一般的です。具体的な手順は以下の通りです。

ファイルシステムの作成

ファイルシステムの管理

作成したファイルシステムの管理には、tune2fs(extファイルシステム用)やxfs_admin(xfs用)といったコマンドが使用されます。例えば、tune2fsを使用してext4ファイルシステムの設定を変更することが可能です。

3. 一般的なファイルシステムタイプ

Linuxではいくつかのファイルシステムタイプがサポートされており、用途に応じて選択することが重要です。以下は代表的なファイルシステムタイプです。

コマンド説明
ext3ext3は、Linuxで広く使用されているジャーナリングファイルシステムで、ext2ファイルシステムの後継として登場しました。ジャーナリング機能により、システムクラッシュや突然の電源断からの回復が速くなります。
ext4最も一般的なLinuxのファイルシステムであり、ジャーナリング機能を持ち、データの信頼性が向上しています。ext4は、安定性と速度のバランスが良いため、個人のPCやサーバーにも広く利用されています。
xfsxfsは、大容量ファイルや高速な書き込みが必要なシステムで利用されます。特にデータベースやファイルサーバーに適しており、スナップショットやデータの圧縮機能を提供します。
btrfsbtrfsは、スナップショット機能や圧縮、自己修復機能を備えた新しいファイルシステムです。ファイルシステムの管理が容易で、ストレージの拡張性や効率性に優れています。
f2fsフラッシュメモリ向けに最適化されたファイルシステムで、特にSSDやeMMCのようなフラッシュストレージに適しています。
iso9660iso9660は、主にCD-ROMやDVD-ROMなどの光ディスクメディアに使用されるファイルシステム規格です。このファイルシステムは、光ディスクにおけるデータの標準的な配置方法を定めています。
UDFUDFは、光ディスクやその他のストレージデバイス向けに設計されたファイルシステムで、iso9660の後継として登場しました。主にDVD、Blu-rayディスク、USBフラッシュドライブなどの書き込み可能なメディアで使用されます。

4. スワップ領域について

スワップ領域は、システムメモリ(RAM)が不足した際に使用されるディスク領域であり、仮想メモリの一部として機能します。スワップ領域を設定することで、システムがメモリ不足の際にハングアップせずに動作を維持することができます。

スワップ領域の作成例:

ここで、/dev/sd2はスワップ領域として使用するパーティションです。swaponコマンドでスワップを有効にすることができます。

5. ファイルシステムのマウントとアンマウント

ファイルシステムは、物理デバイス(ハードディスク、SSD、USBドライブなど)に格納されたデータにアクセスするために、システムに「マウント」して利用します。マウントとは、ファイルシステムを特定のディレクトリに接続し、そこからファイルにアクセスできるようにする操作です。アンマウントは、逆にファイルシステムを切り離し、デバイスを安全に取り外すための操作です。

Linuxでは、mountコマンドとumountコマンドを使ってファイルシステムをマウントおよびアンマウントします。

ファイルシステムのマウント

ファイルシステムをマウントするには、mountコマンドを使用します。マウントは、デバイスとマウントポイントというディレクトリを指定して行います。マウントポイントは、ファイルシステムが接続されるディレクトリで、通常は/mntや/mediaが利用されますが、任意のディレクトリを指定できます。

例えば、/dev/sda1というパーティションを/mntにマウントする場合、次のようにコマンドを実行します。

このコマンドを実行すると、/dev/sda1の内容が/mntディレクトリに表示され、そこからファイルを読み書きできるようになります。

例:ファイルシステムをマウントする

例えば、/dev/sda1という外部ドライブを/media/usbというディレクトリにマウントしたい場合、次のようにコマンドを実行します。

これで、/media/usbにアクセスすることで、外部ドライブ内のファイルを操作できるようになります。

マウントのオプション

mountコマンドには、さまざまなオプションを付けてマウントをカスタマイズできます。以下は代表的なオプションです

  • -t:マウントするファイルシステムのタイプを指定します(例:ext4、xfs)。bashコードをコピーする 
  • -o:特定のオプションを指定します。例えば、ro(読み取り専用)やnoexec(実行不可)など。bashコードをコピーする 
  • -v:詳細な出力を表示します。マウントの進行状況やエラーを確認できます。bashコードをコピーする 
永続的なマウント(/etc/fstabを使用)

一度マウントしたファイルシステムは、再起動後に自動的にマウントされるわけではありません。システムの起動時に自動的にマウントするためには、/etc/fstabというファイルに設定を追加する必要があります。

/etc/fstabファイルに、マウントするデバイスとマウントポイント、ファイルシステムタイプなどを記載します。例えば、/dev/sda1を/mntにマウントする設定は次のように記載します。

これで、システムが起動するたびに/dev/sda1が自動的に/mntにマウントされます。

ファイルシステムのアンマウント

ファイルシステムをアンマウントするには、umountコマンドを使用します。アンマウントは、ファイルシステムへのアクセスを停止し、デバイスを切り離す操作です。

アンマウントするには、マウントポイントまたはデバイスを指定します。例えば、/mntをアンマウントするには次のようにコマンドを実行します。

また、デバイス名を指定してアンマウントすることもできます。

アンマウント時の注意点
  • アンマウントを行う前に、マウントされているディレクトリ内のファイルが使用中でないことを確認する必要があります。ファイルが開かれていたり、プロセスがファイルシステムにアクセスしていると、アンマウントできない場合があります。
  • lsofコマンドやfuserコマンドを使って、ファイルシステムを使用しているプロセスを確認できます。

または

これらのコマンドを使って、ファイルシステムを使用しているプロセスを確認し、プロセスを終了させてからアンマウントすることができます。

6. ファイルシステムの整合性チェックと修復

ファイルシステムの整合性を維持するためには、定期的なチェックと修復が重要です。特に、システムがシャットダウン不完全であった場合や、ディスクの物理的な問題が発生した場合には、ファイルシステムが壊れることがあります。そのため、定期的なチェックと修復作業はシステムの安定性を保つために欠かせません。

Linuxでは、fsck(File System Consistency Check)コマンドを使用して、ファイルシステムのエラーをチェックし、修復することができます。fsckは、指定したファイルシステムに対して以下の作業を行います:

  • ファイルシステムのメタデータを確認し、破損している場合には修復
  • ファイルシステム内での不整合を検出し、修復
  • 破損したファイルを隔離し、可能な限り復旧

fsckコマンドの使い方
ファイルシステムの整合性をチェックするためにfsckコマンドを使用します。例えば、/dev/sda1というパーティションのファイルシステムをチェックするには以下のコマンドを実行します。

このコマンドを実行すると、システムは自動的にファイルシステムを確認し、エラーが発見されると修復を試みます。

例: fsckの実行
例えば、次のようにコマンドを実行した場合、ファイルシステムにエラーがあったと仮定します。

出力例:

この場合、fsckはエラーを修復し、破損していないかを確認します。e2fsck(ext2/ext3/ext4ファイルシステムのチェックツール)は、実際に問題が見つかると、修復するかどうかを尋ねることがあります。たとえば、「修復するか?」という確認メッセージが表示されることがあります。

例文:

このメッセージは、ファイルシステムが正常であり、エラーがないことを意味します。

コマンドのオプション

fsckコマンドには、いくつかの便利なオプションがあります。例えば、-yオプションを使用すると、すべての修復を自動的に承認します。手動で確認することなく、エラーを修正する場合に便利です。
例文:

-nオプションを使用すると、修復せずにエラーメッセージを表示するだけになります。これを使うことで、実際に修復作業を行う前にエラーを確認できます。
出力例:

ブート時の自動チェック

多くのLinuxディストリビューションでは、システム起動時に自動的にファイルシステムのチェックを行います。もしファイルシステムに問題が発見されると、fsckが自動的に修復処理を行います。この処理が長時間かかる場合もあるので、定期的にディスク状態を確認しておくことが推奨されます。

例えば、システム起動時に「ディスクにエラーがあるため、fsckが実行されています」といったメッセージが表示されることがあります。

ファイルシステムの修復後

ファイルシステムが修復されると、fsckコマンドは修復後の状態を報告します。報告には、修復したエラーの数や修復内容が含まれます。例えば、次のような報告が表示されます。

これは、ファイルシステムに問題がなかったことを意味します。

ファイルシステムが修復できない場合

fsckがファイルシステムを修復できない場合もあります。その場合、手動でさらに調査したり、バックアップからの復元が必要です。例えば、物理的なディスク障害がある場合や、データが完全に破損している場合には、fsckでは回復できないことがあります。

そのため、定期的なバックアップと、fsckによる早期のチェックが非常に重要です。システムの信頼性を確保するために、バックアップの重要性を忘れないようにしましょう。

おわりに

今回の記事では、LinuC101試験に向けての学習の一環として、ファイルシステムの基本的な内容、ファイルシステムのマウントとアンマウント、ファイルシステムのバックアップなどについてまとめました。ファイルシステムの正しい管理は、Linuxシステムの安定性を保つために不可欠です。今回紹介したファイルシステムの作成と管理、各種ファイルシステムタイプ、スワップ領域の使用方法、マウントとアンマウント、整合性チェックとバックアップをしっかり理解し、実際の操作を繰り返すことで、LinuC 101試験にも十分に備えることができるでしょう。

今回はここまで
最後までご覧いただきありがとうございました!

Laravel Sailで記事投稿フォームを作成してみた

こんにちは。22年度入社の中島です。

前回はLinuxについて書きましたが、今回は少し前に学習していたLaravel Sailについてまとめました。

●Laravel Sailとは
Dockerを使った開発環境であり、ターミナルでコマンド実行するだけで、DockerでLaravel環境を一発で作ってくれる便利なコマンドラインツールです。
Laravel Sailを使うメリットは次の通りです。

・開発に最低限必要なツールを一度にインストールでき、インストールの手間を省ける
・本番環境と同じ環境を手元に用意して、動作を確認できる
・PHPのバージョンが異なる複数のプロジェクトの管理が楽にできる
(Laravel 8.x からLaravel Sailは標準でインストールされています。)

●なぜLaravel Sailを使っているのか?
Laravelの学習するときに使用していた技術書がLaravel Sailでの環境構築、実装方法を紹介しているのを見て、docker環境との連携も取りやすいと思ったため、復習を兼ねてSailの紹介をやってみようと思いました。


使用したテキスト:『Laravelの教科書』

Laravel Sailのセットアップ及びLaravelトップ画面の表示
1.Docker Desktopをインストール
Dockerのインストールです。Dockerの公式サイトからDocker Desktop のインストーラーをダウンロードします。

2.Laravel Sailをインストールするディレクトリを予め作成しておきます。
今回はtest-projectフォルダを作成しました。

3.Laravel Sailのインストール
Ubuntuまたはターミナルで、次のコマンドを実行します。(今回はUbuntuを使用)

4.途中でパスワードが求められたらPCのパスワードを入力。

5.下記メッセージが出たらインストール完了です。

6.「test-project」ディレクトリへ移動します。

7.Dockerコンテナを起動します。

これによりLaravel Sailが使用する複数のDockerコンテナが起動します。
起動したコンテナについて、Docker Desktopのウィンドウで確認してみましょう。

※./vendor/bin/sail コマンドを毎回入力するのは大変です。
これを「sail」だけで使えるようにするため、エイリアス登録を行います。

以降は sail コマンドとして記載していきます。

8.マイグレーションコマンドを実行して、初期テーブルを作成する。

9.ブラウザで「http://localhost/」 へアクセスするとLaravelのスタート画面が表示されます。※Ubuntuまたはターミナルを開いたまま、ブラウザでアクセスしてください。

今回は、Laravelの復習として過去に作成したフォームの一部を紹介したいと思います。
『件名』『本文』にテキストエリアがあり、フォームの下に『送信する』ボタンがあるフォームを作成していきます。

1.モデルとマイグレーションファイルを作成
まずは、モデルとマイグレーションファイルを作ります。下記コマンドを実行して、Postモデルとマイグレーションファイルを作ります。

このコマンドを実行すると、database/migrations 配下と app/Modelsにファイルが作成されます。次にdatabase/migrations 配下に作成されたマイグレーションファイルに、postsテーブルを作成するためのtitleカラムとbodyカラムを設定します。

./database/migrations/(年)_()_(日)_(時刻)_create_posts_table.php

マイグレート実行し、データベースにpostsテーブルを作成

2.ビューファイルの作成
次にビューファイルを作ります。resources/viewsの中にpostフォルダを作り、その中に create.blade.phpファイルを作ります。create.blade.phpファイルの中には以下のコードを追加します。

create.blade.php

3.ビューファイル表示用コードを追加
次にコントローラです。下記コマンドを実行して、PostControllerを作成。

コマンド実行後、app/Http/Controllerの中のPostController.phpを開きます。先ほど作成した resources/views/post/create.blade.phpファイルを表示するためと投稿データ保存のために、下記のように記述します。

PostController.php

4.ルーティングの設定(ビューファイル表示用のルート設定)を追加
ルート設定の作成です。routes/web.phpの中に、下記のuse宣言とフォーム表示用のルート設定と投稿データ保存用のルート設定を加えます。これにより今回作成したフォームがブラウザに表示されます。

web.php

これまで記述したコードによって、次の流れが実現します。

  1. ユーザーがログイン後にhttp://localhost/postにアクセスする
  2. ルート設定により、PostControllerのcreateメソッドに処理が割り振られる
  3. 処理が実行され、resources/views/post/create.blade.phpの内容がブラウザに表示される

    実際に作成したもの

4.件名(title)と本文(body)を入力し『送信する』ボタンを押すことで、PostControllerにフォーム(http://localhost/post)を通じて値が送信される
5.ルート設定により、PostControllerのstoreメソッドに処理が割り振られる
6.処理が実行され、件名が$request->titleに、本文が$request->body にそれぞれ入っているため、Post::create() に渡してやることでpostsレコードの対応するフィールドに値がセットされる
7.returu back()によっての元ページに戻る

いかがでしょうか。

今回は振り返る形でLaravel Sailのことを書きました。
今後も学んだことを忘れないようにLaravelやLinux、業務で行った作業なども復習する形でブログ更新していきたいと思います。

今回はここまで
最後までご覧いただきありがとうございました!

ヘルパー関数のあれこれ!紙屋03

おつかれさまです!
‘23年度入社の紙屋です!
9月に入って朝晩の暑さがすこーーしずつ和らいでいたような気がしますね。早く日中の暑さも和らいでいくといいですね。

8月で課題の会員登録のアプリケーションを作り終えました。
外部研修でもLaravelでwebアプリケーションをつくりましたが、そのときはとりあえずの実装を優先して、「この関数がどんな仕事をしているのか、どんな機能があるのか」ということを考えていませんでした。
そこで、今回はLaravelにおけるヘルパ関数に焦点をあてて振り返ろうと思います!

ヘルパ関数とは?
Laravelに搭載されている独自の関数のことで、いろいろなところで呼び出せる便利な関数です。

Laravelの公式ドキュメントをみえると数えただけで213個ありました(今回Laravel ver9で実装)。
まだまだ分からないことが多いので、今回は使ったものに触れながら振り返ります!
今回の会員登録フォームで使用したヘルパ関数は、
・view ・redirect ・route ・request ・session
・old ・dd ・dump ・config
でした。
Contollerや入力フォーム、処理の確認で使うものが多く、外部研修でも使っていたので、コードレビューいただく前から使っていました。しかし、config関数は教えていただいてからの導入でした。

よくアドバイスいただく内容として、同じコードで内容量が多く、その処理を複数個所で使用する場合は、可読性や再利用性を考えてコーディングした方が良いと教えていただきます。
今回config関数をどこに用いたかというと、formタグで会員情報の登録や編集を行う箇所でバリデーションを実装するときに、バリデーションの中身は同じものなので、バリデーション時にコードが冗長にならないように利用しました。

まずは、config関数の公式ドキュメントを確認します。
config関数は設定変数の値を取得します。設定値はファイル名とアクセスしたいオプションを「ドット」記法で指定します。
とあります。

となっており、「/config/(.phpファイル)」内に記述されている配列を呼び出します。
では、私はどのように実装したかというと、
Controller内には以下のように記述し、

「/config/mySetting.php」ファイル内に

と記述しました(教えてもらいながらですが…)。

これでバリデーションチェック時の項目をController内に何度も記述する必要が無く、バリデーション内容の変更・修正時も配列の中身を記述することでスッキリします。

ちなみに、ヘルパ関数がどんな処理をしているのかは、「/vender/laravel/framwork/src/illuminate/Foudation/helpers.php」ファイル内に記述してありました。

確かに配列があればキーを返してくれているみたいです。

ちなみに、今回使用した「ドット記法」についてちょっと触れると、配列からの値の取得時にキーを「.」でつなげることで、多次元配列の場合、より深い階層へネストし値を取得してくれます。
例えば、Arr:get()関数の公式ドキュメントを参照すると、

となっています。$arrayのような多次元配列から値を取得したい場合は、第2引数のキーの部分をドット記法で、欲しい値までネストしていきます。
ちなみにArr::get()関数に第3引数をセットすると、第2引数に指定したキーが存在しない場合の値を返してくれます。

改めて振り返ってみると、「なるほど!」と思いました!
今後も、いろいろと忘れないようにまとめていきたいと思います。
では、また次回!!


パスワードはハッシュ化する!!紙屋02

こんにちは!
’23年度入社の紙屋です!
日に日に暑さが増すなか、台風もやってきて大変ですね。
私は出身が鹿児島県なので台風には慣れっこです。
学生のうちは台風が来ると「学校が休みになるんじゃないか」とそわそわしていましたが、社会人になると「台風きたら出勤どうしよう…」と不安でそわそわしてしまいます(笑)

現在は、課題として会員登録フォームをPHPでの実装、その後フレームワークを使った実装がひと段落終えたところです。調べながら、分からないところが教えていただきながらの実装だったので、ちょっとずつまとめをしていこうと思います。

まずはとりあえず機能の実装を!と考え、新規登録フォーム、検索機能、編集・削除機能を実装しました。その中でセキュリティ対策への考えはまだまだ足りず、データベースへ登録する際に、エスケープ処理を行わなければならないことは覚えていましたが、パスワードに対しては何も処理をしていませんでした。
レビューいただいた際に、「え・・ハッシュ化って?」「まだ処理がいるの?」と混乱しました…。なので、今回はハッシュ化について調べてみました。

今回、PHPプログラミングで実装した内容は、

です。
最初は直観的に

をそのままDBに登録していました。

レビューいただいた際に、このままでは、DBを攻撃された場合、個人情報が盗まれてしまう危険性があると教えていただきました。

確かに!ログイン情報を盗まれてしまったらなりすましなんて簡単にできますね。

password_hash関数をマニュアルで調べてみると、


◦$passwordには登録するパスワードの値が入って、
◦$algoにはハッシュ化に使用するパスワードアルゴリズム定数が入って、
◦$optionsには各アルゴリズムがサポートするオプションが入る
とのこと!

アルゴリズム定数のPASSWORD_BCRYPTを使うと
◦”$2y$” crypt フォーマットを使ったハッシュになる
◦長さは常に 60 文字
◦オプションのcostは省略時はデフォルトの10が入り、ハードウェアの性能が許容できるなら高くも設定可

とのことでした。
上記のpassword_hash()関数で登録しなおすことで、

ちゃんとハッシュ化されていました。
これで一安心です!

知らないことが多くて調べて、コーディングして、エラーと闘う日々です。
今後も、いろいろと忘れないようにまとめていきたいと思います。
では、また次回!!

VeeValidateでデフォルト値検査を外す話

福岡開発センターの野田です。
年度末ということで忙しい日々を過ごしています。

弊社では、Vuejs/Nuxtjsを使った開発を行っています。フロントでの値検査を行う場面も増えてきたと思います。ある案件でフロントでの値検査にVeeValidateを利用していたのですが、カスタマイズした検査が有効にならず何でだろうと調べてみました。有効にならなかったのは、Inferred Rules というものが有効になっていてためであることが分かりました。

Inferred Rules

https://vee-validate.logaretm.com/v2/guide/inferred-rules.html#example

この Inferred Rules ですが、例えば type=”email” に対して VeeValidate をかけると何もしなくても email のバリデーションルールが適用されるというものになります。

対象となるinput属性と値は以下になります(上記サイトより抜粋)。

AttributevalueRule
type“email”
type“number”
type“date”
type“datetime-local”
type“time”  or   depending on the step value
type“week”
type“month
minval
maxval
patternrgx
requirednone
maxlength“val”
minlength“val”

これを無効化する方法は以下のコードとなります。useConstraintAttrs: false のオプションを指定することでInferred Rulesの設定を無効化することができます。Inferred Rulesはカスタムルールより優先度が高いため、結構扱いが難しいな、と感じています。どこでも使われるようなもののためそういう実装になっているのでしょうけど、メッセージをカスタマイズしたいときは足かせになりました。

[/crayon]

こういう設定調整ができるのは、しっかりポイントが抑えられていて人気のライブラリであることを感じます。また何かTipsが出てきたときは紹介したいと思います。

[bug]マルチプロセスでlog4netのファイルローテーション時に一部ログが欠損して困った

福岡の香月です。

log4netのRollingFileAppenderを使って日付で出力ファイルが切り替わる設定をしていたところ、日付が変わって新しいファイルへの出力が始まると先頭に出力されるであろうログがなぜか出力されない現象に遭遇しました。
設定はこうです。
複数のプロセスで同じ設定を用いて、同じファイルに対してログ出力します。

[/crayon]

AppenderはRollingFileAppenderを指定しています。複数プロセスで使用するため、lockingModelはInterProcessLockを指定します。これによりファイルストリームを開きっぱなしにして、mutexで排他制御しながら末端にシークし書き込みを行うことで、複数プロセスから効率的にログ出力を行ってくれます。
複数プロセスから使う場合はこれ以外にもMinimalLockを指定できますが、書き込むたびにファイルのオープンクローズを実施するため速度が求められる場合は不向きでしょう。さらに複数プロセスからの出力が同時に走った場合、片方はオープンできないためログが出力されません。

この設定でビルドし、業務終わりにアプリを起動して一晩中実行させ、翌朝出社して確認しても日付が変わった後のログの内容が足りませんでした。
最初はlog4netの使い方が悪いのか、自分のプログラムにバグがあるのかさんざん悩んだんですがさっぱりわからない。トレース用に埋め込んだログも当然のように出ていないのでどうしたものかと思いました。

しかし、プロセスが1つの場合はちゃんと期待通りのログが出ていました。問題があるのは複数プロセスの場合だけだったのです。

そこでlog4netのロジックを確認することにしました。 幸いなことにソースはこちらから取得できます。
https://github.com/apache/logging-log4net
すると、ファイルが切り替わったあとは最後に書き込んだプロセスのログが先頭に来て、それ以前のログが破棄される作りになっていたのです。

少しずつソースを見てみましょう。今回使っているのはRollingFileAppenderです。日付が変わるときにファイルを切り替える部分は、RollOverTime()という関数であることがわかりました。こうなっています。
https://github.com/apache/logging-log4net/blob/master/src/Appender/RollingFileAppender.cs

[/crayon]

ふむふむ、SafeOpenFile()で新しいファイルをオープンしに行くわけね。そして第二引数がfalseと。そしてSaveOpenFile()の実態はベースクラスFileAppenderにありました。
https://github.com/apache/logging-log4net/blob/master/src/Appender/FileAppender.cs
ここから次の順番で呼び出されていきます。

  • RollingFileAppender.OpenFile()
  • FileAppender.OpenFile()
  • FileAppender.InterProcessLock.OpenFile()
  • FileAppender.LockingModelBase.CreateStream()
[/crayon]

ここでSafeOpenFile()の第二引数で指定されたfalseは、CreateStreamのappendに代入されていることがわかりました。この場合FileMode.Createが指定され、FileStreamインスタンスが作成されます。
ではこのFileMode.Createはどのような動きをするかというと、

オペレーティング システムが新しいファイルを作成することを指定します。ファイルが既に存在する場合は上書きされます。これには Write 許可が必要です。
FileMode.Create は、ファイルが存在しない場合は CreateNew を使用した要求、ファイルが存在する場合は Truncate を使用した要求と等価です。

https://docs.microsoft.com/ja-jp/dotnet/api/system.io.filemode?view=netcore-3.1

複数のプロセスでログ出力を行う場合、FileStreamを最後に作成するプロセスによりそれまでのプロセスが作成したログファイルの中身がTruncateされて、つまり削除されてしまうわけです。
発生している現象とも合致するのでこれが問題であることを確信しました。

対応するためにはRollingFileAppender.RollOverTime()から呼んでるSafeOpenFile()の第二引数をtrueに知ればよいわけです。実際に修正して確認してみると、見事欠損することなく必要なログが出力されていました。
めでたしめでたし。

なお、SafeOpenFile()はRollingFileAppender.RollOverSize()内からも呼び出しているのでここも忘れずにtrueに変更しましょう。