- Obsidianプラグイン活用術
- AIと企業、若手エンジニアの現状
- CSSにおけるfont-sizeの単位
- AIアシスタントによる専門業務効率化
- マリオカートワールドとAI生成画像
- LLM活用のためのMarkdownデータ統合
- GoogleとAIシフトによるネット支配の変化
- Postman入門
- AIの利用コストと今後の展望
- 勾配ブースティング決定木の理論解説
- UUID短縮ライブラリ開発
- Claude 3.7システムプロンプト流出に関する解説
- 正しい質問力の重要性
- SUNEASTのType-C接続USB SSD
- 数十人規模チームにおける自律性と時間管理
- 故意によるファイル削除と損害賠償
- Git入門
- CursorとObsidianの組み合わせに関する考察
- AI PMワークフローaipm_v0の使用例と応用
- DeepWiki-OpenのDockerによるmacOS環境構築
- Reactのレンダリング処理解説
- Cursorのバックグラウンドエージェント
- DockerのMCP Toolkit
- Visual Studio Code v1.100アップデート
- EmotionからCSS Modulesへの移行
- 生成AI技術の最新動向
- 委託先選定におけるセキュリティチェックシート
- スクラム開発における品質向上とデリバリースピード両立
- GitHub CopilotのGPT-4.1モデル一般提供開始
- Gmailの3DES暗号化方式サポート終了
Obsidianプラグイン活用術
Markdown対応テキストエディタObsidianとその活用法を紹介する記事で、日記、コード、AIプロンプト、ブログ下書きなどへの利用方法を、ツェッテルカステン方式を用いずに拡張性の高さを活かして解説しています。Thino、Dataview、Tag Wranglerなど、便利なプラグインを多数紹介しており、著者の個人的なおすすめプラグインとその機能についても詳しく説明されています。
AIと企業、若手エンジニアの現状
AIの使用が禁止されている大手企業で、若手プログラマーがAI利用を希望して退職した事例が報告されました。AI使用禁止の背景にはセキュリティ上の懸念などが考えられますが、AI活用が業界標準になりつつある現状とのギャップが、このプログラマーの退職理由として注目されています。プログラマーはAIによる生産性向上を期待しており、AIを使えない環境に不満を感じていたとされています。この事例は、企業におけるAI導入の安全性と社員のスキルアップ支援の重要性を改めて浮き彫りにしています。
CSSにおけるfont-sizeの単位
Chromeの文字拡大機能を「極大」で検証できるならrem、そうでないならpxを使うべきという見解を提示し、remのみを使うことの非効率性やレイアウト崩れの可能性、基準となるフォントサイズがない場合のpxの適切性、状況に応じたpxとの使い分けの必要性、そしてrem使用時のレイアウト崩れを防ぐ設計の重要性について解説しています。
- 可能であれば Chrome の文字拡大機能をサポートするために
remを使用する。 - ただし、実際に Chrome の文字拡大機能を「極大」にして検証することが必須条件。これに時間的・労働的なコストを割けないのなら
pxを使用したほうがいい。
「font-size には rem を使いましょう」という教えが独り歩きしており、実際に Chrome の文字拡大機能を「極大」にして検証していない人が多いため。
font-sizeだけremを指定すればいいという訳ではなく、文字拡大に伴ったレイアウトの変更に耐えうる設計とする必要がある。つまり、font-sizeだけでなく文字の拡大に依存する余白やサイズなどもフォントサイズを基準とした相対値（remやemなど）で指定する必要があるということ。- 以下はあるゆる箇所がアンチパターンであるものの、わかりやすい例として提示する。以下のようなコードだと文字拡大が起こった際にフォントサイズが親要素の高さを超えて切り取られてしまう。
.anti-pattern {
overflow: clip;
block-size: 30px;
font-size: calc(24 * var(--to-rem));
}- また、別の理由として「
font-sizeにはremを使いましょう」と言いつつも、:rootのfont-sizeに16pxなど絶対値を指定しており、 Chrome の文字拡大機能が動作していないというケースも見受けられた。実際に文字拡大機能を動かせば機能していないことは一目瞭然なはずなのだが、こちらから伝えるまでは分からなかったということは実際に文字拡大機能を動かして検証していない証拠だろう。
つまり、実際に文字拡大機能を動かして検証している実装者は少なく、文字拡大機能を動かした結果レイアウトが崩れる、文字が読めなくなる、良かれと思って相対値指定したのに全く機能していないという本末転倒な事態に陥っているケースが多い。
それならば px 指定をしたほうがレイアウト崩れの心配もなく、開発コスト的にも余計な労力を割かなくて良い。
答えは「No」である。
- 確かに余白やサイジング、ブレイクポイントなどの全てを
remなどのフォントサイズを基準とした相対値で指定すれば、全てが拡大されるのでレイアウト崩れが起こることは少ない。 - だからといって全てを
remにすればいいかと言われると、そうではない。文字拡大機能ユーザーが望むことは行政の Web サイトにある文字拡大ボタンのような挙動であり、全てをズームしたいわけではないからである。 - 仮に全てをズームしたいのならズーム機能を利用するはずであり、ズーム機能との住み分けができていない。
そもそも相対値は何かを基準に指定したいから使うものであり、別に何も基準としたいものがない場合に使用するのはセマンティックとは呼べない。
- 例えば僕の身長は 182cm であるが、人に自分の身長を教える際にピカチュウの高さの 4.44 倍ですなんて言わない。普通であれば絶対値(cm)を答えるだろう。
- これと同じで、別に何も基準としたいものがない余白やサイジングをわざわざ「これは
font-sizeの ◯ 倍です」と指定するのはおかしい。 - 原則的には絶対値の
pxをベースとして考えて、何かを基準にサイズ指定をしたい場合のみ相対値を使うのがベターではないか。
「段落の間は 1 文字分あけてください」「ボタンのpaddingは 1.5 文字分あけてください」というオーダーならemを使うし、「数字リストは桁が増えた分に備えて数字 3 つ分幅を保ってください」というオーダーならchを使う。至極単純な話であり、相対値とはこうあるものだろう。
コンポーネント間の余白やborder-radiusにremを用いる実装を見かけるが、それは本当にフォントサイズを基準としているか？は自問自答したい。
※ちなみに :root の font-size をハックしてリキッドレイアウトを組む実装が紹介されていたが、意味がわからないのでやらない。
rem への変換方法には色々と方法があるが、calc()関数で事足りるのでそれを使う。
@property --root-font-size {
syntax: "<length>";
inherits: false;
initial-value: 16px;
}
:root {
--to-rem: calc(tan(atan2(1px, var(--root-font-size))) * 1rem);
}
.heading {
font-size: calc(24 * var(--to-rem));
}remの計算を簡略化するためにルートのfont-sizeを 62.5%にするアプローチがあるが、使用しない。外部の CSS やサードパーティ製の CSS（特に WooCommerce や Shopify などのプラグインは顕著）がremベースで指定されている場合に都合が悪い事態が起こり得るため。- Sass の関数を自作して効率化しなくても上記の
calc()関数をスニペット登録すればコストは同じ。CSS 標準でできることは可能な限り CSS 標準でやったほうがいい。- また、誰も使っていないので知らない人は多いだろうが CSS 標準で 1 つ目のパラメータを 2 つ目のパラメータで割った余りを返す
rem()という関数がある。Sass の変換関数はrem()という命名がメジャーになっており、この全く関係のない CSS 標準の関数とバッティングすることは覚えておくと良い。
- また、誰も使っていないので知らない人は多いだろうが CSS 標準で 1 つ目のパラメータを 2 つ目のパラメータで割った余りを返す
上記の理由から実際に文字拡大機能を動かして検証を行い、かつ拡大時のレイアウト調整に時間的・労働的コストを掛けられる現場のみがremを使用するのが良い。
そこまでコスト掛けられないよって人はpxを使用したほうが良い。
加えて CSS 初学者や CSS よくわからない人がこの検証フローを行うのは辛いと思うので、そういった方々もpxを使用したほうがいい。
AIアシスタントによる専門業務効率化
AIアシスタント「Cursor」を用いて、PMBOKやDMBOKといった専門知識体系を組み込み、業務効率化を図る試みが紹介されています。具体的には、Markdownファイルで整理した知識体系をCursorに読み込ませることで、知識の一貫性向上、学習コスト削減、ミス防止、ドキュメント作成効率化といった効果が期待できるとされています。 さらに、PMBOK、DMBOK以外にもITILやデザイン思考などへの応用可能性も示唆しており、AIを活用した知識習得と業務改善の具体的な方法と展望が示されています。
マリオカートワールドとAI生成画像
任天堂の新作モバイルゲーム『マリオカート ワールド』において、ゲーム内のグラフィックに不自然な点があるとして、RedditなどSNSでAI生成画像使用疑惑が浮上しました。この疑惑を受け、任天堂は公式にAI生成画像は使用していないと発表しています。この件は、生成AI利用における著作権や品質問題への懸念が背景にあり、任天堂のAI技術活用への慎重な姿勢を示す出来事となっています。
LLM活用のためのMarkdownデータ統合
様々なデータソース（ブログ記事、Zenn記事、Notionメモ、Twitter投稿など）をMarkdown形式に統一し、GitHubで管理する方法を紹介。自動化ツールやスクリプトを用いたMarkdownへの変換方法、GitHubサブモジュールによる複数リポジトリの効率的な管理、そしてAIエディタや自作ツールとの連携による検索・記事作成・プレゼン資料作成への活用まで、LLMを活用した効率的な情報管理・データ活用のための具体的な手順を解説しています。
GoogleとAIシフトによるネット支配の変化
Googleの25年にわたるインターネット支配が、生成AIの急成長によるAIシフトで揺らいでいるという日本経済新聞の記事です。 生成AIの台頭は国際的な規制や著作権問題といった課題を生み出し、Googleは独占禁止訴訟にも直面、イノベーションの優位性を失いつつあります。 iPhoneでのGoogle検索数の減少など、AIシフトの影響は既に顕著に見られ、記事ではGoogleの現状とAI技術による今後の展望を分析しています。
Postman入門
APIリクエストツール「Postman」の入門記事です。GUIを用いた直感的なAPIリクエストの送信・確認方法、コレクション機能によるリクエストの整理・管理、環境変数を使った開発環境と本番環境の切り替え、Pre-request Scriptによるリクエスト送信前の処理実行といった機能を解説しています。
AIの利用コストと今後の展望
スタンフォード大学が発表した400ページを超えるAIに関する年次調査報告書を日本経済新聞が解説しており、生成AIの急速な発展と、それに伴う国際的な規制の必要性、中国DeepSeek社などのオープン型AIモデルの台頭によるビジネスや科学分野への影響、AI推論コストの285分の1への大幅削減、ChatGPTやMidjourneyなどの生成AI拡大による著作権問題などの新たな課題が示されています。日経新聞の記事には、AIに関する詳細な分析やデータが掲載されています（会員限定）。
勾配ブースティング決定木の理論解説
勾配ブースティング決定木(GBDT)は、複数の決定木を組み合わせることで高精度な予測を行うアンサンブル学習手法です。勾配降下法、ブースティング、決定木の3要素から構成され、回帰問題と分類問題の両方に対応できます。XGBoost、LightGBM、CatBoostといった主要な実装ライブラリがあり、それぞれに異なる特徴があります。高い予測精度と容易な前処理がメリットですが、計算コストやハイパーパラメータの調整が課題となります。不均衡データにも有効で、様々なデータ分析タスクに適用可能です。
UUID短縮ライブラリ開発
UUIDをBase58でエンコードし、36文字のUUIDを22文字程度に短縮するNode.js、Deno、ブラウザ対応のライブラリ「uuid58」の紹介です。URLへの最適化に役立ち、エラー処理も万全で安全なAPIを提供、パフォーマンスにも優れ、必要な機能だけインポート可能です。
Claude 3.7システムプロンプト流出に関する解説
2025年5月、Anthropic社のAIモデル「Claude 3.7 Sonnet」のシステムプロンプトが流出しました。システムプロンプトはAIの動作を規定する初期設定で、AIの性格や安全対策などが記述されています。この流出は、プロンプトインジェクション攻撃や安全対策回避のリスクをもたらし、AIの透明性とセキュリティのバランスに関する課題を浮き彫りにしました。AI開発者と利用者は、セキュリティ強化と倫理的な利用を心がける必要があります。
正しい質問力の重要性
インターネットやAIで容易に情報が得られる現代において、「調べればわかる」「聞けばわかる」という考え方は、問題提起の重要性を軽視しているという指摘です。 適切な質問をするには高度な思考力や分析力、創造性が必要であり、それは正確な情報獲得に繋がり、今後ますます重要なスキルとなると論じています。 さらに、自分は何を知らないのかを理解する能力こそが知性の本質であると主張しています。
SUNEASTのType-C接続USB SSD
旭東エレクトロニクスが、超小型外付けSSD「Portable SSD Nano」を発売しました。128GB、256GB、512GBの3モデルがあり、価格は1万円台前半です。約2.8gと軽量で、最大読込速度450MB/s、最大書込速度400MB/sを実現しています。USB Type-C接続で、PC、スマートフォン、タブレットなど幅広く対応し、小型で持ち運びやすく、機器に挿しっぱなしでも使用できます（ただし、強い圧力は避けてください）。
数十人規模チームにおける自律性と時間管理
カケハシ社の小田中氏が、数十人規模のチームにおける時間不足問題とその解決策を解説しています。アイゼンハワーマトリクスを用いて、重要だが緊急でないタスクの放置が緊急事態を招くことを指摘し、定例ミーティング削減実験による余白創出と、その結果生まれたチーム横断連携不足という課題を報告。さらに、サブチーム分割やローテーションといったチーム構造最適化の試行錯誤と、目標共有とメンバーの主体性を重視したアプローチによる第二領域への取り組み促進について詳細に説明しています。
故意によるファイル削除と損害賠償
徳島地方裁判所の判決（令和5年ワ38号）では、元従業員が退職時に会社のサーバーから約230個のフォルダ内のファイルを故意に削除した事案において、不法行為が認められ、約570万円の損害賠償が命じられました。元従業員は引継ぎ不要と主張しましたが、裁判所は認めず、適切な開発環境やバックアップの欠如も過失相殺の理由とはなりませんでした。これは、故意によるデータ削除に関する貴重な判例です。
Git入門
JJUGセミナーにて開催されたGit入門の発表内容を紹介する記事です。Gitによるバージョン管理の基本概念、ローカルリポジトリとリモートリポジトリ、コミット、ブランチ、マージといった重要なキーワード、git init, git clone, git add, git commit, git push, git pullといった基本コマンド、そしてプログラミング以外の用途におけるバージョン管理への活用方法などが解説されています。
CursorとObsidianの組み合わせに関する考察
Mekannの記事「CursorとObsidianは理想の組み合わせではなかった」では、AIライティングツールCursorと知識管理ツールObsidianを併用することの危険性について論じています。具体的には、AIに文章生成を頼る「Vibe writing」と呼ばれる傾向が、思考の浅薄化や批判的思考力の低下につながるとしており、AIが生成した完成度の高い文章に安心し、内容の吟味を怠る危険性を指摘しています。AIは補助ツールとして使い、最終的な判断は人間が行うべきであり、AIの限界を理解し、主体的にAIを使いこなすことの重要性を訴えています。
AI PMワークフローaipm_v0の使用例と応用
みやっち氏作成のAI PMツール「aipm_v0」を用いたプロジェクト管理手法と、オンライン定性調査プラットフォーム構築事例を紹介。LLMを活用したプロジェクト計画の自動生成・最適化、タスク管理、進捗報告などの機能と、Difyなど既存ツールとの比較、メリット・デメリットを解説し、「Vibe PM」という新たなプロジェクト管理スタイルの可能性にも言及しています。
DeepWiki-OpenのDockerによるmacOS環境構築
DeepWiki-OpenをmacOS環境でDockerを用いて試した体験レポートです。Google API KeyとOpenAI API Key、Dockerのインストールが必須で、READMEに従ってコマンドを実行すれば容易に動作します。このツールはソフトウェアに関するドキュメントを自動生成し、チャット形式での閲覧やMarkdown形式でのエクスポートにも対応しています。今後の課題として、大規模ソフトウェアへの対応や生成されるドキュメントの精度検証が挙げられています。
Reactのレンダリング処理解説
Reactのレンダリングメカニズムを簡潔に解説した記事です。仮想DOM(Fiberノード)を用いたcurrentとworkInProgressの2つのツリー間の差分検出によるレンダリング、workInProgressツリーにおけるレンダリング処理(関数コンポーネント実行、差分検出、後処理)、コミットフェーズでの実DOM更新、Placement、Update、Deletionなどのフラグを用いた効率的な差分検出、巡回アルゴリズムによるツリー処理、そしてcurrentとworkInProgressツリーの入れ替えによるリソース再利用といったプロセスが説明されています。
Cursorのバックグラウンドエージェント
Cursorエディタの外部で動作する非同期型遠隔処理エージェント「Cursor – Background Agent (Preview)」は、長時間実行タスク（バグ修正、機能追加、リファクタリングなど）をバックグラウンドで処理し、複数のエージェントの同時実行と必要な時の通知を可能にするプレビュー版です。現在、機能拡張中です。
DockerのMCP Toolkit
DockerのMCP Toolkitは、AIエージェントとコンテナ化されたMCPサーバーを統合するDocker Desktop拡張機能で、セキュリティリスクのあるローカル実行に代わる安全なコンテナ環境を提供します。信頼できるDocker MCPカタログからツールを簡単にインストールでき、Claude Desktopなど主要クライアントとの統合も容易です。この記事では、Docker Desktop上でMCP Toolkitを使用する手順を解説しています。
Visual Studio Code v1.100アップデート
Visual Studio Codeがv1.100にアップデートされ、AI関連機能が大幅に強化されました。具体的には、インストラクションファイルやプロンプトファイルによるAI機能のカスタマイズ、チャットによる拡張機能の提案とインストール、チャットのパフォーマンス向上などが挙げられます。その他、画像生成機能の追加、セキュリティ強化、言語機能の強化、エディターの使い勝手改善なども含まれています。
EmotionからCSS Modulesへの移行
PR TIMESがフロントエンドのスタイリングライブラリをEmotionからCSS Modulesに移行した経緯と、その過程で発生した問題とその解決策について解説しています。Remix SPA Modeへの移行失敗と、将来的なReact Server Components対応を見据え、Tailwind CSSのメンテナンスコスト懸念なども考慮してCSS Modulesを選択。移行作業ではhappy-css-modulesやpostcss-nestingなどを活用し、CSS詳細度の問題やEmotionとCSS Modules混在時の問題などに対応しました。
生成AI技術の最新動向
生成AIウィークリー第94回では、AIモデル評価ランキング「Chatbot Arena」の問題点分析、GoogleによるAI生成動画の動きの一貫性評価手法「TRAJAN」の開発、Microsoftによる推論能力の高い小型言語モデル「Phi-4-reasoning」の発表、そしてMicrosoftによる1ビットLLMの効率化技術「BitNet v2」と、AIの自己議論による精度向上手法「CoRT」の発表について解説しています。「CoRT」はAIに繰り返し自己議論させることで考えを深め、精度を向上させる技術です。
委託先選定におけるセキュリティチェックシート
企業における委託先からの情報漏洩が深刻な問題となっている中、本記事では委託先選定におけるセキュリティ対策として、チェックシートの有効性と課題について解説しています。特に、チェックシートを用いた選定において、回答の正確性や適切なシート作成の難しさ、そしてその対策について、サイボウズとNRIセキュアの事例を交えながら説明しています。自動車業界におけるサイバーセキュリティガイドラインとチェックシート作成の事例も紹介することで、より実践的な委託先選定方法を学ぶことができます。
スクラム開発における品質向上とデリバリースピード両立
LayerX社のエンジニアリングマネージャーが、スクラム開発における品質向上とデリバリースピードの両立について、QAという技術を導入した取り組みを紹介しています。開発現場の複雑化と手戻り増加により品質とスピードの両立に課題を抱えていた同社は、ドキュメント整備、探索的テスト、開発者相互検証などの施策を通して手戻りを削減。その結果、障害件数や修正件数が半減し、品質とデリバリースピードの両立に成功しました。現在は、導入した技術の定着化とリアーキテクティングに取り組んでいるとのことです。
GitHub CopilotのGPT-4.1モデル一般提供開始
GitHub CopilotがGPT-4.1をデフォルトモデルとして一般提供開始し、プレミアムプランの利用制限開始日が6月4日に変更、VS Codeユーザー向けにエージェントモードとMCPサポートが開始、新しいPro+プランも提供開始されました。Anthropic、Google、OpenAIのモデルも一般提供され、GitHub製品プレビュー版のデータはモデル学習に使用されません。
Gmailの3DES暗号化方式サポート終了
Googleはセキュリティ強化のため、Gmailが5月30日以降、古い暗号化方式3DESのサポートを終了することを発表しました。これにより、3DESを使用するメールシステムからはGmailへのメール送信ができなくなります。3DESはセキュリティ上の脆弱性があるため、推奨されておらず、Gmailでは基本的に最新のTLS方式が使用されています。5月30日以降は、3DES使用によるメール受信不可の警告が表示される予定です。
